Tom Auger

Thanks for your thoughts Randy.

The issue appeared to be related to Changeset 29834 that we had recently pulled down in an update (I know, I know, what were we doing using Trunk in a production site? It was an accidental svn pull).

I’m not sure this issue would affect other users, but if anyone else experiences similar issues, you might start by following this ticket on Trac.

Thanks Ian – the visual editor is working.

Thanks for staying on top of the Markdown issue – since the WC MS doesn’t have a “formats” pull down menu, it’s still a manual process to enter heading levels etc. So markdown will really speed things up!

Hi thanks to both of you for the great response. I _would_ indeed love to see Markup supported by all the WordCamp CPTs, if it’s not too big a deal to push up a change to the MS.

However, it’s true that I’m not getting the visual editor. I’m having a bit of trouble figuring out how to post a screenshot to demonstrate what I see. Essentially the ribbon is permanently in Text (HTML) mode and there are no tabs to switch modes. This is the case across browsers as well, and there are no errors in the console.

Maybe it’s a capabilities thing?

Arg. RTFM. Just read this: https://jetpack.me/support/markdown/ which clearly states that you must enable CPT support programatically.

Sadly, this is not possible on the WC MS, since lowly Admins do not have access to, well, anything.

If I write and patch with a CPT selection UI how quickly can you get that pushed into a JP update? haha – I’m dreading having to code 64 speakers and sessions in HTML by hand.

Sorry for the post. After more investigation there was a conflict with a pagination plugin that has nothing to do with SSP. I’m closing this topic.

Hey Mark, I know you’re super busy, but is this something you might get the chance to look into, say, after 3.5 is out? Would be great to be able to use your plugin with transients.

Meeble – thanks for posting this. Sounds like you experienced exactly the same issues I did.

Third Update: somehow during the latest update (again, not sure whether this is a WP update or a VFB update), the “Notification” settings were lost. What was in fact happening was that the “Notification” option was still turned on, but the reply-to address and other required fields were missing. This is odd, because you cannot turn Notifications on and submit the changes if the required fields are blank. It makes me wonder whether the Options field names were changed during the last update?

At any rate, this explains the reason the emails were being sent: the email to the admin mailbox were going through, but the error was being generated by the second email (the notification email).

The solution: check to see whether you have Notifications turned on. If you do, be sure the “reply-to” address is filled in.

Second Update: with WP Mail SMTP activated, set to SMTP and properly configured (test mails work fine), I continue to get the same error with V 2.6.4, though the emails ARE being sent through.

Update: surprisingly, the emails DO go through, even though the error message is displayed. Just to be clear: using php mail(), the email IS sent through, but the Error message is displayed to the end user. The form submission is also logged in the DB.

Something does appear to have changed recently. I have a number of sites running VFB and one running VFB Pro. I have recently done a full update (WP & Plugins) on the non-pro sites (haven’t yet updated the pro site). Since that update, we’re getting this error. I can try the WP SMTP workaround, but I’m curious – what has changed in the latest update? I wish I could remember whether there was a VFB update or whether it was just updating WP to 3.4.2 that did it…

Hey Matt, I’m sorry if my comments appeared to be defamatory. I can tell from your responses that you’re upset. That was not my intention.

I don’t know what FUD is, but I guess it’s not a nice acronym. At any rate, I accept that I haven’t checked too deeply into your code, but then again, you could have just explained how your code is structured to prevent security issues.

Not trying to bust your chops. Just looking at ways to improve your already great plugin.

Be well,

Tom

Even scarier. I haven’t checked to see whether the upload form uses nonces or not, but if not, there could be a real hole here.

It’s important to note that as soon as I removed the APC Object Cache Backend file, the transients were being properly set and found again. This more than anything else, points to something related to APC Object Cache Backend.

In a nutshell, here’s what I’m doing…

Generate the transient key using a hash that’s comprised of the user login, email and timestamp.

// Transient keys need to be less than 45 characters in length. wp-hash generates a 30-character string, but still, to be safe...
$transient_key = substr( wp_hash( self::$registering_user->user_login . self::$registering_user->user_email . 'validate' . time() ), -30 );

Set the transient and store the user ID
if ( set_transient( $transient_key, self::$registering_user->ID, self::EMAIL_VALIDATION_TIMEOUT ) ){

(I should note that… const EMAIL_VALIDATION_TIMEOUT = 28800; // 8 hours )

Generate a URL that I email to the user’s email. It includes a query arg ‘k’ which contains the transient key for the transient we just created.
$validation_url = add_query_arg( array( 'action' => 'validate', 'k' => $transient_key ), site_url( self::REDIRECT_LOGIN_FORM ) );

Then that all gets sent to the user. Once the user clicks that link…

if ( $transient_key = $_REQUEST['k'] ){
  if ( $user_id = get_transient( $transient_key ) ){ // THIS is where we end up with APC Object Cache Backend DISABLED. }
  else { // throw error message - THIS is where we end up with APC Object Cache Backend ENABLED. }

The only thing I __don’t__ know at this point is whether the transient is set, but can’t be read back, or whether it never gets set in the first place.

Awesome, Ryan. Thanks for this.