Critique my first plugin? For viewing incomplete Gravity Forms submissions

(Leland Fiegel) #1

Believe it or not, I’ve never released a plugin that I’ve written essentially from scratch. Just little forks here and there.

Even though I’m a very confident and experienced theme developer, plugin development is something I just don’t feel comfortable with at this time.

I’m hoping more experienced plugin developers can take a look at my code and critique it.

To be clear, this isn’t a “how do I promote my plugin” topic because I don’t care if this plugin gets popular at all. It’s a “would you do something differently and if so, why” topic.

Story behind the plugin

I have a “client” that uses very long Gravity Forms. As such, Save and Continue is a very useful feature for users of the form, who often complete part of the form, save it, and revisit it later to finish it off.

For those not familiar with Gravity Forms, once the user hits “Save and Continue” they are given a URL like this:

Along with a prompt to input their email address so they can email that URL to themselves. Once that URL is visited again, the form can be seen again just as they left it, ready to be worked on some more.

However, for whatever reason, users occasionally misplace the link, and request support from the client in order to recover it so all their form progress doesn’t seem lost (even though it’s still safely stored in the database).

On the backend, the incomplete entries are saved in the database, but there is no way to view them in the WordPress admin interface. You need to go into the database and find the token.

For most web developers, this isn’t a huge problem. Just hop on over to phpMyAdmin, go to the wp_rg_incomplete_submissions (may vary depending on multisite and/or custom prefix) table and search for it. However, without going into too much detail, this particular client has strict security rules, and many hoops have to be jumped through before a database search can be performed.

This plugin provides a rudimentary interface in the WordPress backend to access any incomplete entries, so regular WordPress site admins (and not database admins) have a way of recovering these tokens.

It basically just reads from the database table where these incomplete entries are stored, and outputs that information on an admin page.

I released the plugin on GitHub: Access Incomplete Entries for Gravity Forms

Some things I’ve taken care of already:

  • Exit if the file is accessed directly
  • Make sure only those with the manage_options capability can access the page
  • Make sure the correct database prefix is used, ensuring this still works on multisite or a custom database prefix is used
  • Escaped all output from the database. Since I’m not writing to the database, I figure that’s all I’d need to worry about in terms of escaping/sanitizing?

Some specific questions I was wondering about:

  • Since this plugin is useless without Gravity Forms, should I add some sort of conditional to make sure Gravity Forms is active before running any code?

  • At the moment, this plugin page is listed under the “Tools” menu. Would it make more sense under “Forms” (where the rest of the Gravity Forms stuff is)?

  • The <table border="1" cellpadding="10"> part makes me barf. Are there any WordPress admin classes I can take advantage of for basic table styling? Although I could, I’d rather not add CSS just for something as simple as table styling.

  • Would OOP code be a better choice here? Or for a plugin this simple, would it not matter much?

  • I plan on eventually submitting this to, and want to make sure this plugin is translation-friendly. I know “language packs” were recently introduced. Is there anything I need to do to add translation-friendliness, other than make the strings translatable? Should I generate a .pot file as well?

Any other feedback (not limited to the above questions) would also be much appreciated. Thanks!

(Jeffrey Carandang) #2

Yeah it’s kinda surprising that this is your first plugin, just thought you are creating both themes and plugins before :slight_smile:

You should definitely need to add notice that Gravity Forms is required when the plugin was activated, this will be of great help on every users specially those who have Gravity Forms before and decided to deactivate it.

You can use <table class="form-table"> which has default styling from admin core.

It will be very user-friendly if you add ‘Setings’ Link below the plugin name. You can use this action :

I hope this helps :slight_smile:


(Leland Fiegel) #3

Thanks Jeffrey! Very helpful.

Yeah, I figured people would be surprised, but it’s true. :slight_smile:

Great idea. I’m assuming use admin_notices with either the notice-warning or notice-error class, if an is_plugin_active check turns up false?

Cool. I also found a plugin called WordPress Admin Style that gives examples of all the available UI elements, and found the widefat class might also work too for tables.

Will do!

(Jeffrey Carandang) #4

No problem :slight_smile: Goodluck with the plugin!


(Hudson Atwell) #5

Starred! Will try and check it out later. Seems like a plugin that will come in handy. I’d recommend adding a short description and a github file so those surfing github for help can run into your plugin and star it.

(Anh Tran) #6

Glad that you make plugins, too. It’s a total difference experience from developing themes.

Just took a quick look at your plugin and here are some feedback:

  1. Localization: make sure all text are translatable. Your plugin also need to load textdomain. If you plan to release on, you probably don’t need to create a languages folder with .pot file inside, cause the translation are made automatically via (but you still need to load_plugin_textdomain).
  2. You definitely should check for GF is active. Maybe a simple check like if ( ! class_exists( 'GFAPI' ) ) { echo 'error'; return; }. That will prevent from a fatal error if GF is not active (and you know the only way to get rid of fatal error is modifying the code, which is hard and sometimes impossible for end-users).
  3. The admin heading now uses h1 instead of h2. h2 is still ok, but not as semantic as h1.

You might want to convert the code to OOP if you want. But I think it’s not needed. Your plugin is simple enough to use procedural code.

(Leland Fiegel) #7

I know! I feel like a fish out of water here. Although some theme development-related skills came in handy (I knew I had to escape output coming out of the database before displaying it), everything else I had to just research and try on my own.

Yeah, this is what I figured. I might try to convert it to OOP and throw it up on GitHub just to practice, but will keep the procedural style in the public version of the plugin just because I think it would be easier for end users to understand if they were to peek at the code.

Another thing I was curious about is the database query.

// Grab incomplete submissions
$incomplete_submissions = $wpdb->get_results(
	SELECT uuid, source_url, form_id, date_created, ip
	FROM $table_name

My “client” only has a few of these incomplete submissions at a time, and I believe Gravity Forms automatically clears these out after 30 days.

But, I’m wondering if a site that has a ton of incomplete submissions at any given time, it might potentially crash their server opening the plugin page with such a large set of incomplete submissions being pulled in at once?

Is there some best practice way to paginate database results like this in WordPress so the query isn’t unbounded? Or is it not something worth worrying about?

(Leland Fiegel) #8

Wanted to give an updated on this.

This is now in the directory under the name Save and Continue Link Recovery for Gravity Forms

Changes since I initially posted here:

  • Changed the name from “Access Incomplete Entries for Gravity Forms” …I feel the new name more accurately describes what the plugin does. It just recovers links, but doesn’t let you edit any of the data like the Partial Entries add-on (which I discovered just a few days ago).

  • Used the “widefat” class for the table. Way better than the inline HTML attributes I was using to style the table.

  • Added a “Settings” link so users could quickly access the admin page after activating.

  • Made all text translatable.

One thing that I didn’t do was check if Gravity Forms was active first. Since all the plugin does is read a database table (which could be there even after Gravity Forms is deactivated/uninstalled) I decided to leave that part as-is.

Thanks everyone for your feedback, it’s much appreciated. :slight_smile: