[Plugin: podPress] Auto detect file size and doesn't work after upgrading to 8.8.9

Thank you both for all the help.

Here’s an update.

I’ve installed the latest development version 8.8.9.2 RC2.

1. Auto detect works fine on local hosted mp3s whether I just enter the filename or I enter the complete url.

2. Auto detect also works on remote hosted mp3s ONLY when I enter a remote URL into the Podpress general setting “URL of the media files directory”

3. However Auto detect still fails (i.e. returns full html of wordpress page) when I enter a remote mp3 URL into the media location field on a post page.

I’ve enabled debug log and it contains messages for auto detect attemps for scenarios 1 and 2 above but no message at all is in log for scenario #3.

Here’s pastebin of log file
https://wordpress.pastebin.com/download.php?i=vgg3XVsB

Thank you!

Would do you mean with “auto detect”? The file size detection or the duration detection or both?

2. Auto detect also works on remote hosted mp3s ONLY when I enter a remote URL into the Podpress general setting “URL of the media files directory”

I don’t understand why it should be necessary to put a remote URL into the “URL of the media files directory” setting.
If you like to have the dropdown menu at the post editor page then you need to insert the a full path of a folder which contains media files into “Absolute path of the media files directory (optional)” field. There will be no dropdown menu (instead of the simple input field) if the folder does not contain media files.
If both “Location of the Media Files” are not pointing to same directory then the download URLs on the front page of the blog will in most cases not work.

But if you specify a full URL to a file (on a remote server or on the same server as the blog) as the file location in the field below the editor then it is not important for the detection of the file size and the duration of that file what the “Location of the Media Files” settings are.
I understand that exactly this is not working in some of your blogs and I would like to find out why this:

3. However Auto detect still fails (i.e. returns full html of wordpress page) when I enter a remote mp3 URL into the media location field on a post page.

happens.
For instance when I insert an URL of one of the mp3 files of the The Medical Podcast page which are hosted on archive.org as the location (in my blog), it is no problem to retrieve at least the file size. I also do not need to change the “URL of the media files directory” setting. It can remain the URL of the uploads/ folder of my blog.

I have made a further Development Version. This version includes 3 further control point for the log procedure and several minor JS and PHP bug fixes.
Please, download this version, change the PODPRESS_DEBUG_LOG constant again and test the file size and duration detection while the “Absolute path of the media files directory (optional)” option is not set (the field is empty).
Please, post the log file entries of these tests.

Thanks,
Tim

Dear Tim,

Thank you again for all your help!

I installed the new Development Version.

However, no entries are made in the log file when I attempt to use either autodetect button when a full URL is entered into the media file location field.

An entry is made when I enter a file name of a file in the upload directory. You can see that at https://wordpress.pastebin.com/download.php?i=G0cBPpuY

Thank you again!
Jeremy

Jeremy and Tim,
This thread is starting to get long and some of the assumptions I had at the beginning might be wrong. Can I confirm a couple of points?
1. The only issue here is that the functions which require the remote file to be downloaded are not working, right?
2. These functions work on one of Jeremy’s shared hosting service providers but not on another one (HOst Gator), right?

Since it doesn’t seem to be permissions related, another possiblity is that Host Gator has disallowed curl() or fopen() on their server for security reasons and that is why the file cannot be detected (the download fails). Tim, how is podpress downloading the remote file? What PHP function does it use? Does it call a WP function for this? Does your debug code have logic to check if the function call to transfer the remote file completed properly?

Thanks,
Ray

Ray and Jeremy,

as I understand it, the file size detection (no download necessary) and the duration detection (download necessary if the file is on a different server) do not work in the same way. If Jeremy enters an URL of a media file which is on a server which is not the server of the blog then the file size and the duration field get populated with the code of the 404 page or the front page depending on the blog.

The result of the last test (no entries in the log file) shows that somehow the request does not get through to the routine in the podpress_backend.php file which would call the function to detect the file size or the duration (podpress_admin_functions.php) when he enters a full URL. The whole process does not get started.
It seems to be not important whether it is an URL to a remote file or local file. (But that this is my assumption.)
But if he enters only a file name of a file which is in the folder which is reachable with the “URL of the media files directory”.

A typical request with a full URL as the location would look like this https://www.example.com/wp-content/plugins/podpress/podpress_backend.php?action=getfilesize&filename=https://www.example.com/wp-content/uploads/example.mp3

But a typical request with only a file name in the “Location:” field would look like this https://www.example.com/wp-content/plugins/podpress/podpress_backend.php?action=getfilesize&filename=example.mp3
In this case a function in the podpress_admin_functions.php file will the URL to the file name and detect the file size. The last log is from such a case: https://wordpress.pastebin.com/G0cBPpuY The filename parameter is only the file name (lori-wallach.mp3).

For me it looks like the problem of the URL and maybe of the value of the &filename= paramter.

This

2. Auto detect also works on remote hosted mp3s ONLY when I enter a remote URL into the Podpress general setting “URL of the media files directory”

supports my assumption.

Maybe the problem is that the URL of the media file does not get escaped with the right method. But I would think that the log file should contain at least one line “podpress_backend.php – param filename:”. The value of the paramter &filename= gets escaped with escape() (JS) or encoded with encodeURI() or encodeURIComponent() (JS) that depends on whether it is a file from the dropdown menu or the input field. (The JS which starts after the click on the file size button is in line 63-88 of the /js/podpress_admin.js)

But I think we could rule out a problem with the URL escaping method if the same URL would work in a different blog.
Jeremy would you post the URL of the media file from the last test? Or could you try to retrieve the file size of this file by inserting the full into a “Location:” field in one of the blogs where the auto detection works. (File size detection works without a download and it take usually only seconds regardless whether it is a remote file or not.)

Or maybe the problem are some additional entries in the .htaccess file.

@ray:

Tim, how is podpress downloading the remote file?

It opens a connection with fsockopen() and tries to create a local file in one of the tmp folders with tempnam() or fopen() (see lines 1144 and 1181-1264 in podpress_admin_functions.php)
Other used PHP functions are fwrite() to send the HTTP request and later to write to the file. fgets() to receive the response.

Does your debug code have logic to check if the function call to transfer the remote file completed properly?

Well, after fclose($fpRemote); is a further control point (podPress_var_dump('podPress_downloadFile - (file) before return');)
and there would also be a notice in case the download would stop because of a time limit. On the other hand there is no custom error message in case the fclose() calls went wrong.

My next questions for Jeremy would be: What is in the .htaccess file for instance of the Transpartisan Innovations blog? Does the file contain other then these lines while you are using a non-default Permalink scheme?
Are you using any other plugins (besides podPress) in the Transpartisan Innovations blog? Which plugins?

(If the .htaccess file exists, it is in the root directory of your blog (the same folder which includes the wp-config.php file). The .htaccess is maybe a hidden in the view of your FTP or SSH client.)

Tim

Hi Guys,

Thank you!

Here is the pastebin link to the two .htaccess files:
https://wordpress.pastebin.com/download.php?i=GsTkqPsw
It shows the file from the functioning site and the one from the site with the error.
They appear to be the same

Here is one of the URL’s I’m testing:
https://www.archive.org/download/StopTheU.s.KoreaTradeAgreement/lori-wallach.mp3

So to review the functioning of the Auto Detect buttons:

1) entering just file name (if file is in uploads dir) e.g. “lori-wallach.mp3” – BOTH AUTO DETECT BUTTONS WORK

2) entering full URL to file in local UPLOAD dir e.g. “https://www.transpartisaninnovations.com/wp-content/uploads/lori-wallach.mp3” – ALSO BOTH AUTO DETECT BUTTONS WORK

3) entering full URL to remotely hosted mp3 e.g. “https://www.archive.org/download/StopTheU.s.KoreaTradeAgreement/lori-wallach.mp3” – AUTO DETECT BUTTONS DO NOT WORK

4) entering partial remote URL leaving off MP3 file name in general setting “URL of the media files directory” e.g. “https://www.archive.org/download/StopTheU.s.KoreaTradeAgreement/”
and then entering just the file name in the media location field in the post e.g. “lori-wallach.mp3” – ALSO BOTH AUTO DETECT BUTTONS WORK

Thank you!! Jeremy

Thanks again for the report!

Both .htaccess files are looking okay to me. It seems that they do not include problematic things.

I have tested the URL to the archive.org hosted file and it is not a problem for me to retrieve the file size and the duration regardless of the values in the section “Location of the Media Files” of the General Settings of podPress.

Jeremy, please, try to find out whether other plugins have an influence in the third case. Please, deactivate other plugins temporarily.

Regards,
Tim

Thank you Tim.
To rule out plugins I created a completely fresh install of WordPress without any plugins.
I appreciate your help here.
Jeremy

To answer Ray’s question:
Yes, this is happening on all WordPress installs that I have hosted at Host Gator shared hosting.

WordPress installs I have hosted on Apollohosting and Lunarpages shared hosting are functioning ok in this regard. I’m trying to migrate all to HostGator and/or Lunarpages because they seem to run much faster that Apollohosting’s servers (for WordPress installs anyhow). Apollohosting doesn’t host the MySql databases on the “localhost”. They have external machines running their mysql databases and it seems to really slow down WordPress. Sorry for the off topic rant.

Thanks again!
Jeremy

Jeremy,
Try adding this to your .htaccess file

php_flag allow_url_fopen on

put it right before or right after the wordpress section. (remember to
backup the original .htaccess file first)

-Ray

Dear Ray,
Thank you for the suggestion!

When I include that line either before or after the wordpress section I get the following server error when trying to access the site (site works normally again when I remove the line):

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, [email protected] and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8q DAV/2 mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at https://www.transpartisaninnovations.com Port 80

Jeremy,
That error means that the server doesn’t understand what you put in the .htaccess file.
I use that flag with no problems. I am using PHP 5.2.17 running as an apache module. Do you know what version of PHP you are running (type php -v at the shell prompt) and do you know if you are running php as cgi or as an apache mod?

@tim,
I had a hunch it was because you were using fopen(). I have had problems on some hosts who block fopen() by default for security reasons. The preferred way to download by url from php seems to be with curl(). BUT – I can’t reproduce jeremy’s problem on my server. I’ve been trying using remote urls from here:
https://www.archive.org/details/AlJolson
and it always works – even when I add php_flag allow_url_fopen off to my .htaccess. So I am probably wrong about this – sorry.

By the way, getting the size, durations and even ID3 tags for remote files works great. I didn’t realize how robust podpress had become since you started patching and improving it. Great work Tim!

-Ray

Hi Ray,
Thank you again!
PHP is 5.2.15 and it is running as CGI.
That and other PHP settings for the server are here:
https://www.themedicalpodcast.com/phpinfo.php
Jeremy

Jeremy, sorry but I think I was wronag about php flags being the cause of your problems on Host Gator.

https://support.hostgator.com/articles/cpanel/php-settings-that-cannot-be-changed

says that allow_url_fopen is on by default. Further, I can’t break podpress by turning off allw_url_fopen on my own site so I’m sorry I spoke too soon. For what it’s worth this functionality works great on my site and HostGator seems to have an active support guy. Maybe he can give you a clue what is different about their server?

-Ray
P.S. you might try renaming your .htaccess file temporarily just to see if this is related to the bulletproof plugin stuff – but since you said it works on other servers, I doubt that’s it…

I still think taht the problem has something to do with the parameters of the request which gets send if you cli9ck on the Auto Detect buttons.

If Jeremy enters a full URL of a file on a remote server then the request seems to get redirected to the front page or the 404 page of the blog (and the log file was empty)

Maybe it is some kind of a security feature of those servers. Which does not allow requests with URLs which include a further URL to a remote server (or to a different domain).
If one enters a full URL as the location of a media file then a typical requests looks like
“https://www.example.com/wp-content/plugins/podpress/podpress_backend.php?action=getfilesize&filename=https://www.example.net/downloads/example.mp3”
And the problem seems to exists only if auch an request includes an URL of a different domain:

1. Auto detect works fine on local hosted mp3s whether I just enter the filename or I enter the complete url.

Jeremy, I think that you could ask the hosting provider if there is a server side feature which filters request like the one above.

I will take further look on the encoding of the value of the &filename= parameter.

Regards,
Tim