Jump to content


These Forums Are Now Read-Only


For TubePress support, please post a question here or open a support ticket and we will be glad to assist.


Photo

Unable To Unserialize Php From Vimeo With Tubepress Pro


  • Please log in to reply
22 replies to this topic

#1 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 02 August 2013 - 11:00 PM

Just bought TubePress Pro to use with Vimeo, and quickly hit a wall.  Running WP 3.6 multisite on server running Nginx, if that matters.

 

I added both the consumer key and consumer secret on the Feed tab (which means a registered the app with Vimeo).

 

I put the default shortcode in a page.

 

I selected one of the defaults for Which Videos? - "Videos This Vimeo user likes" (keeping the default value)

 

WIth those settings, instead of seeing a pretty gallery, I see "Unable to unserialize PHP from Vimeo".  If I switch to YouTube, TubePress displays as expected.

 

Suggestions to resolve?  Is the callback URL on the Vimeo app setup required?

 

On a separate note, can I have both the free TubePress and TubePress Pro installed?  In other words, can I rename the pro version to add "Pro" and use a folder name of /tubepress-pro ?



#2 eric

eric

    Lead Developer

  • TubePress Staff
  • 2787 posts

Posted 05 August 2013 - 08:23 PM

instead of seeing a pretty gallery, I see "Unable to unserialize PHP from Vimeo".  If I switch to YouTube, TubePress displays as expected.


Typically this error means that TubePress is getting empty/malformed data back from Vimeo. Could you share a link to a page that shows the problem? Feel free to PM me with the address if you can't share it with the world. Please also ensure that debugging is enabled from WP Admin > Settings > TubePress > Advanced. Your site's debugging output should help us track down the issue.
 
 

Is the callback URL on the Vimeo app setup required?


That's not required, no.
 
 

On a separate note, can I have both the free TubePress and TubePress Pro installed?  In other words, can I rename the pro version to add "Pro" and use a folder name of /tubepress-pro ?


You should be able to, yes, since WordPress identifies plugins by their directory name plus main plugin file. So in your case you might have the two plugins:

  • wp-content/plugins/tubepress-pro/tubepress.php
  • wp-content/plugins/tubepress/tubepress.php

The plugins should show up individually at WP Admin > Plugins.



#3 eric

eric

    Lead Developer

  • TubePress Staff
  • 2787 posts

Posted 05 August 2013 - 09:31 PM

Thanks for the PM. Taking a look at your debug output, the message that Vimeo buried in there is

The consumer key passed was not valid.

In the documentation we have a few troubleshooting steps for Vimeo errors like this under the "Vimeo OAuth" section. Usually if the server has the wrong time we see a different message, so my bet is that the key was entered into TubePress incorrectly or the key and secret were swapped.

 

Could you triple-check that the Vimeo key and secret are correct?



#4 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 05 August 2013 - 09:33 PM

Thanks, Eric.  PM sent.  I double-checked the Vimeo settings on the Feed tab, and they're correct AFAIK.  I am using the Vimeo oAuth credentials for the app I created, not the access tokens that appear below them on the same screen (did try those but same result).  I am not sure if this matters, but this is a Vimeo Pro account.

 

I can confirm that you can run both regular & pro versions.  One suggestion: on the Settings menu, I'd make the label use the plugin name if possible.  I renamed the plugin to TubePress Pro so it was clear which was activated, so it would be great if this showed the name.



#5 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 05 August 2013 - 10:00 PM

I think you replied while I was checking if I should use the access tokens, which wasn't a good route. 

 

What URL did you use to see debugging info?  The ones I tried 404'd, so I can't see the debugging info after I've gone back to the correct settings.  Feel free to post the URL here if that's easier.  <- Scratch this.  I figured out the adjustment necessary to get the debug info to show up, and I see responses to the GET requests from Vimeo.  I don't catch an explanation for the error I reported, though.

 

I just re-copied/pasted, making sure which one goes where, and get the same error.  I created a 2nd app and tried those settings, and now have it set using the 2nd set of credentials - same error.

 

I doubt it is a server time issue, because we have multiple web servers and our admin has the times sync'd properly.  Could HyperDB be an issue?  I recall another plugin that had some authentication issues based on how data was stored.  We have other plugins running that use oAuth without problems. 



#6 eric

eric

    Lead Developer

  • TubePress Staff
  • 2787 posts

Posted 05 August 2013 - 10:56 PM

I can confirm that you can run both regular & pro versions.  One suggestion: on the Settings menu, I'd make the label use the plugin name if possible.  I renamed the plugin to TubePress Pro so it was clear which was activated, so it would be great if this showed the name.

 
Good idea! Will add that to our tickets.
 
 

What URL did you use to see debugging info?  The ones I tried 404'd, so I can't see the debugging info after I've gone back to the correct settings.  Feel free to post the URL here if that's easier.

 


No clue why Vimeo still isn't accepting your credentials. Could you PM me a screenshot of your app's page from developer.vimeo.com? I'll try using your consumer key and secret to see if it works from here.



#7 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 05 August 2013 - 11:08 PM

PM sent.  Note that if you took just 1 look at the debug info, it is now probably different.  Thanks in advance.



#8 eric

eric

    Lead Developer

  • TubePress Staff
  • 2787 posts

Posted 06 August 2013 - 02:19 PM

Just tried your credentials in my test environment and they worked for me. Used the following shortcode:

[tubepress mode="vimeoAlbum" vimeoAlbumValue="140484" vimeoKey="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxb10e4" vimeoSecret="xxxxxxxxxxxxxxxxxxxxxxxxxxxxff5d"]

So it's got to be something with your server(s) that Vimeo doesn't like. Looking again at your debug output, it seems like it might have something to do with a time of day problem. Looking at your debug output right now, and after doing a hard refresh with my browser, I see:

... oauth_timestamp=1375815970 ...

when the actual current Unix time is 1375820107. A difference of almost 69 minutes. This might mean that I'm looking at a cached version of your page, but it could also mean your server's time is off. One way to verify what time your server has is to create a PHP file with the following contents:

<?php

echo time();

View this file in your browser and compare the output to the correct time.
 
Let's investigate this possibility and if still no luck then we'll dig deeper. Thanks.



#9 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 06 August 2013 - 03:46 PM

The time is correct and there is caching.

 

On the time, I can SSH into the server and get the time by typing date into the terminal, and it matches the current UTC time.  We are running multiple web servers behind a load balancer, and the web servers are synced time wise, and we check this regullary, so it's not a time issue.  However, we do have caching (not via a WP plugin, but via Nginx).  A non-logged in user is served a cache page, but it is never more than 1 hour old.  Cached pages are never served for logged in users, and all my tests have been done when I was logged in, so they weren't cached.  And only the page at the exact URL is cached; I'm pretty sure that parameters stop the caching.

 

I put your shortcode on a separate post (after completing the credentials), and looked at the debug output.  I got oauth_timestamp=1375820032  when the unix timestamp was ..39, so those 7 seconds just could mean that I am slow on a keyboard :)  Also, we have a # of Twitter widgets that use oAuth without a problem.

 

Let me ask a few questions:

 

1) Any special modules on the server for this to work?

2) I don't see my actual credentials in the debug output, so they are converted/encrypted in someway.  Could that be the problem?

3) At the very bottom of debug output, I see something that says Raw result for URL is HTML source for this page, where URL is a link.  The link opens to a "save as" dialog, and when I examine the contents, it says (among other things): "The oauth_nonce passed has already been used.";s:3:"msg";s:13:"Invalid nonce"; -- does this message mean anything or shed any light?



#10 eric

eric

    Lead Developer

  • TubePress Staff
  • 2787 posts

Posted 06 August 2013 - 06:37 PM

I got oauth_timestamp=1375820032  when the unix timestamp was ..39, so those 7 seconds just could mean that I am slow on a keyboard :)  Also, we have a # of Twitter widgets that use oAuth without a problem.

 

Excellent. So we can rule out incorrect time. Vimeo only complains if the time is more than a few minutes off.

 

 

1) Any special modules on the server for this to work?

 

Nothing fancy, no. You can view the detailed requirements here. But TubePress seems to be running normally otherwise for you, so my suspicion is that your servers are good to go.

 

 

2) I don't see my actual credentials in the debug output, so they are converted/encrypted in someway.  Could that be the problem?

 

You will never see your credentials in the output. They are used to generate a signature that is sent to Vimeo for verification (see the oauth_signature=uclaOcf9qtAXkYWJGq7rEq5Bp3w%3D bit in the URL).

 

 

3) At the very bottom of debug output, I see something that says Raw result for URL is HTML source for this page, where URL is a link.  The link opens to a "save as" dialog, and when I examine the contents, it says (among other things): "The oauth_nonce passed has already been used.";s:3:"msg";s:13:"Invalid nonce"; -- does this message mean anything or shed any light?

 

Strange that the error message has changed - I'm not seeing that particular error as I'm looking at the cached version of the page. The oauth_nonce value is a random string (generated here) that is sent to Vimeo to prevent replay attacks. Somehow, Vimeo is seeing a duplicate request coming from your server(s).

 

I wonder if, in addition to incoming load balancing, you have any outbound transparent HTTP proxying set up on the load-balancer? e.g. Squid or Varnish?

 

Is there any way to temporarily move one of the servers out from behind the load balancer?

 

Finally, if you are willing and able to provide me with credentials so I could view a non-cached version of the page, feel free to send them to me.



#11 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 06 August 2013 - 07:06 PM

PM w/credentials sent.

 

Checked the requirements against our config, and we're good to go.

 

On our caching, the cache life is only 1 hour.  Since the site is under development, I doubt the URL under discussion is being viewed much, so you may not necessarily be viewing a cached page. 

 

No outbound transparent HTTP proxying like squid or varnish.  I should also add that we're running memcached and APC, but I doubt those are causing this.  I'm not sure why Vimeo would see multiple requests.

 

Yes, I can ask our admin to remove a web server and test, which would eliminate the load balancer.  We have virtually no problems with the load balancer, so I'd be shocked if it were that.  Won't be the first time I've been shocked though, so it's worth a test if you don't see anything else on login.



#12 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 07 August 2013 - 03:05 PM

Eric - Sent you a PM with the credentials.  I also just did a test where I removed 1 of our web servers from the load balancer and changed my hosts file to point to the IP of that removed web server.  Same problem.



#13 eric

eric

    Lead Developer

  • TubePress Staff
  • 2787 posts

Posted 07 August 2013 - 05:12 PM

Thanks for the credentials. I logged in and viewed the sample page that we've been working with, along with the rest of the TubePress/WordPress settings.

 

Everything looks perfectly correct from what I can see. It seems that Vimeo is rejecting any set of credentials that we plug in, even fresh ones. So clearly they don't like something else about the request. Could be the Vimeo has a problem with your IP space, or maybe something is interfering with the request after it leaves your local enclave.

 

Unless you can think of anything, I'm not sure there's much else I can do from my end. At this point if I were in your shoes I would seek help from Vimeo directly - you can contact them a few different ways listed at the bottom of this page. In theory they should be able to check their server logs for more info.


  • brandon likes this

#14 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 07 August 2013 - 11:25 PM

Thanks for checking, Eric.  I'll raise it with Vimeo and also ask our admin.  We'll track it down somehow.  I'll let you know what I find out.



#15 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 14 August 2013 - 03:42 PM

Eric - I've had extensive discussions with Vimeo and done some testing, and things point back to TubePress.

 

They provided code from their official library, https://raw.github.c...aster/vimeo.php, and a 2nd script into which I put my oAuth credentials.  I'll send you this 2nd script via PM.  I put both on 1 of our web servers while it was still attached to our load balancer, and Vimeo confirmed that it returned everything it should. 

 

Vimeo asked if you provide some sample code which would make the same request using TubePress code instead of the code from their official library.  We could then test that sample connection code.  Vimeo further said that they recommend using the Auhorization header instead of querystring parameters.  They seem to believe it is an encoding issue on the part of TubePress, because they pointed to info in their logs where the provided signature does not match the expected signature. 

 

After you take a look at the PM, please let me know your thoughts.



#16 eric

eric

    Lead Developer

  • TubePress Staff
  • 2787 posts

Posted 28 August 2013 - 04:42 PM

I've just posted TubePress 3.1.2.RC1 (both free and Pro). This version now uses the Authorization header to communicate with Vimeo, as they recommended. With luck this should solve this problem. Give it a try and let us know?

 

Here is the full changelog for 3.1.2, in case anyone is wondering what else has changed.

 

Thanks!



#17 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 29 August 2013 - 12:05 AM

Thanks and great.  I tried Pro RC1 and it appears you've solved the authentication issue by using the authorization header.  So count me as a very happy camper.

 

Since this is an RC, I'll give you some feedback on a few other thngs I noticed, which aren't necessarily big deals to me.  To understand some of the comments, see this draft page.

 

1) Not all the player options work; for example, Fancybox works, Shadowbox among others don't (for Shadowbox, clicking video does nothing; tried FF & Chrome)

2) I changed the player max height on the player tab to get a nice big player in the content area, but that seems to have affected the height of the sidebar widget - even though I used a shortcode with these parameters: thumbHeight='105' thumbWidth='135'.  Is that normal?

3) Somehow I have a TubePress widget in the sidebar (which is the big player described in #2), but this widget was placed before the RC update; I don't have a TubePress widget to drop into a new area.  Is that because it's not multi-instance or do I need new glasses?

4) For the video in #2 using the TubePress widget, I have a shortcode of (without the spaces) [ tubepress video="14454412" thumbHeight='105' thumbWidth='135' ].  However, the same shortcode doesn't work in a text widget - even though I've enabled shortcodes in both text widget content and titles.

5) I saw you renamed the Pro plugin and removed the purchase option from it.  That's a great simplification.

 

If any of the above is due to my missing something, thanks in advance for letting me know.  Once the site is live and the page is finally polished, I'll post back with a link.



#18 eric

eric

    Lead Developer

  • TubePress Staff
  • 2787 posts

Posted 30 August 2013 - 07:47 PM

Thanks and great.  I tried Pro RC1 and it appears you've solved the authentication issue by using the authorization header.  So count me as a very happy camper.

 

Excellent! Very pleased to hear the issue is fixed.

 

1) Not all the player options work; for example, Fancybox works, Shadowbox among others don't (for Shadowbox, clicking video does nothing; tried FF & Chrome)

 

Don't forget to install Shadowbox.js. It's not bundled with TubePress Pro due to licensing limitations. That should fix it for you.

 

2) I changed the player max height on the player tab to get a nice big player in the content area, but that seems to have affected the height of the sidebar widget - even though I used a shortcode with these parameters: thumbHeight='105' thumbWidth='135'.  Is that normal?

 

Hmm no that doesn't sound normal. Changing the height of the embedded player in the content area should have no effect on the widget. But every theme is different so there could be some interference. Do you have a link to a page that shows the problem? I looked in the draft page you sent but didn't see a widget. Let me know and I'll be glad to take a look.

 

3) Somehow I have a TubePress widget in the sidebar (which is the big player described in #2), but this widget was placed before the RC update; I don't have a TubePress widget to drop into a new area.  Is that because it's not multi-instance or do I need new glasses?

 

For the moment you're limited to a single TubePress widget :(  This is very high on our development priority list and we'll be releasing this functionality soon. Keep your glasses, they're working just fine!

 

4) For the video in #2 using the TubePress widget, I have a shortcode of (without the spaces) [ tubepress video="14454412" thumbHeight='105' thumbWidth='135' ].  However, the same shortcode doesn't work in a text widget - even though I've enabled shortcodes in both text widget content and titles.

 

This is probably because TubePress doesn't use WordPress's shortcode library. Until we get the multi-widget functionality, your best workaround would be to either invoke TubePress from your WordPress template or use a widget that allows invoking PHP. If you choose the latter route, please PM me and I'll share with you the recipe to invoke TubePress this way (not something I want to advertise to the world).

 

Let me know what you think and please do post back when you're ready to share your site - it's looking really great so far!



#19 wpperform

wpperform

    Member

  • Members
  • PipPip
  • 15 posts

Posted 30 August 2013 - 10:19 PM

Thanks for the follow up, Eric.  No worries on any of the items.  Re #2 above, I did remove the TubePress widget from that page for a demo, but I just added it back and will keep it there so you have a chance to take a look.  The link is here.  You'll see it's setting the width and height on the iframe to match what I have for thumbnail settings, but the actual video is the right side.  Debug is still on.  If you need login credentials, just let me know.



#20 eric

eric

    Lead Developer

  • TubePress Staff
  • 2787 posts

Posted 02 September 2013 - 09:07 PM

Thanks for putting the widget back. Since you have adjusted the embedded height/width via WP Admin > Settings > TubePress > Player, those settings will act as "defaults" for anything you don't explicitly set via a shortcode. So in your widget, you'll just need to explicitly set the height and width. e.g.

 [tubepress video="14454412" thumbHeight='105' thumbWidth='135' embeddedHeight='160' embeddedWidth='90']

Make sense?