goldenapples

Thanks for the info. I can see the problem in Chrome. I’ll try and track it down and push out a fixed (and probably updated with a few additional features) version early next week.

@kyle –

I haven’t found a replacement for Gravity Forms as far as WP plugins go. I haven’t been building a lot of WP sites lately, so when I’ve come across form requirements, I’ve just been building them myself using some helper classes and javascript snippets I’ve ported from project to project. The corporate site that I was working on and build this for moved to using Marketo hosted forms, a completely different beast though.

mgunay and Kyle –

Can you guys give me some more information related to the problem… Versions of WP and of GF that you’re running, browser info in case its a browser-specific problem?

I just set up a test install with WP3.6 and GF1.7.7, and was able to set up the plugin and get it working on a form without any problems… I’ll have to test some more to identify the problem, but any info you could provide would be helpful.

Thanks for the report.

I moved away from using Gravity Forms so I didn’t check this plugin in the last few versions of GF. I’ll look over their documentation and see if I can find why that’s happening.

I’d like to bump this issue, and maybe suggest making the admin bar display a custom capability rather than just dependant on is_super_admin().

I’m setting up QA testing for a project and it would helpful if my testers could see the debug bar, even while using “Editor” and “Author” accounts for testing.

Yes, its easy enough to hack the plugin. But it would be even easier if there was a way to give certain users access to the debug bar without hacking the plugin.

Sure, you can ping me directly: than at janrain dot com.

But – I think I realize what the issue you’re having is. You’re also using the regular social login plugin, and this uses the same element ID for its widget. So depending on the script loading order, some of the styling of the basic login widget and the actions on authorization are overriding the behaviour of my plugin.

<del>You should be able to fix by using a different element ID – if you go through the main plugin file and replace all instances of “janrainEngageEmbed” with something different.</del>

Actually, there’s no way to include two widgets with different settings on one page. You’ll have to disable the rpx plugin scripts for the pages you have forms on.

Hmm… some issues that I hadn’t thought about before releasing.

About your first issue: The provider icons buttons are just floated
<li>‘s inside a containing div. I’m imagining your theme might have some padding applied to <li>‘s that’s forcing the buttons onto a second row?

I’m not sure how to diagnose the second issue without seeing it. At first I thought it might have to do with being an ajax-enabled form, because different javascript events are triggered on Ajax forms, but I just tried creating a couple of Ajax forms in my test environment and I don’t see that issue. Do you have any other custom Javascript running on that page? Can you open a console and see if there are any notices or errors displayed when the form clears?

OK, I’ve got it. In the javascript configuration settings (lines 103-122 of gravity-forms-janrain-add-on.php), tokenUrl is being set twice. The first one of those should actually be appUrl – when appUrl isn’t set, it falls back on the Janrain default app.

Strange behavior. I’m going to release an update in the next hour or so that fixes this issue. Sorry about the hassle.

Hi,

Let me check into that. I wonder if a hardcoded domain name could have been left in there….

I just noticed this too. Looks like the issue is related to the plugin trying to hook directly to the default WP nonce, and the name of the default nonce action was updated in WP3.5

A quick patch is here: in abt-relative-urls.php:

--- abt-relative-urls.php	2012-12-18 12:45:32.641102283 -0800
+++ abt-relative-urls.php	2012-12-18 12:44:43.237104028 -0800
@@ -167,7 +167,7 @@
 		/* */
 		$posted_type = $_POST['post_type'];
 		$posted_id = $_POST['post_ID'];
-		$nonce_name = 'update-' . /*$post->post_type*/ $posted_type . '_' . /*$post_ID*/ $posted_id;
+		$nonce_name = 'update-post_' .  /*$post_ID*/ $posted_id;
 		if ( empty($_POST) || ! check_admin_referer($nonce_name) ){
 			return $post_ID;
 		}

Basically, WP used to use a nonce action on updating posts named update_{$post_type}_{$post->ID}, and the plugin is looking for that. The action name is just update-post_{$post->ID}, and that makes the plugin choke.

No, I didn’t get any response from the Vanilla developers and decided against patching the entire plugin for just my own use.

It turned out to be simple enough to just grab the json feed from the Vanilla forums install and use that to generate a list of recent discussions, though, which is what I did.

<?php

$forums_api = wp_remote_get( 'https://forum.url/?p=discussions.json' );
$forum = json_decode( $forums_api['body'] );
$discussions = $forum->Discussions;
if ( $discussions ) { ?>
<ul class="listings"><?php
	foreach ( $discussions as $d ) {
		$time = human_time_diff( strtotime( $d->DateLastComment ), current_time( 'timestamp' ) );
		echo "<li><span class='genderpref'>{$d->Category}</span> <a href='{$d->Url}'>{$d->Name}</a> ";
		echo "{$d->CountComments} posts / last $time ago</li>";
	} ?>
</ul>
<?php } ?>

I appreciate the feedback, and yes, this is probably not so useful for most people in its current state. I implemented something like this (but very specifically customized) a couple years ago on a site I built, and since then I’ve heard people asking how to do something similar. Just wanted to push out this plugin as a framework to build upon and demonstrate how this kind of functionality can be achieved.

I will work on regularly updating the plugin and adding features; I just wanted to put it in the hands of a few users so I could get feedback on what features were most important.

Options, customization, support for tagging, and user levels (karma based, and permissions-based) are all next on the agenda. I’ll keep adding a feature or two every week, until either (a) the plugin is stable, useful, and complete, (b) someone else develops a demonstrably better solution, or (c) it becomes obvious that no one is interested…

Ha. I just saw this thread.

Yes, I did start on the process of building another “reddit clone” as a plugin to run in WordPress, back under 2.9. But with a lot of the recent core enhancements, I started to wonder if it was even necessary. A theme that allows front-end posting, post formats (for a reddit; probably bookmarks, asides, images, and default), and a ratings plugin like GD is really all you need.

So, now I was thinking more in terms of making a theme or framework than a plugin. Only downside is that if you wanted to include your reddit alongside your usual site content, you would probably have to go with multisite.

Hi Mike,

Also, the option to use this interface for a different taxonomy and/or post type would be really cool. Was easy enough to do with a global find and replace and an additional hook into ‘save_post’, but it would be cool if those options were built into the plugin as well…

Cheers!

A big +1 to leesalazar’s comments above.

Developer-oriented features get added regularly, usually before most of us recognize the need for them, which is great. But the Editor UI is a pain point for most regular users.

1. Full-screen visual editor is a good step, but not perfect. And it would really be nice to have an expandable html editor area.
2. Discuss adding some of the features from TinyMCE Advanced into core.
3. Allow defining of image intermediate sizes by post type.