[Plugin: podPress] 8.8.5 RC unexpected output error on initialization

If you set ‘PODPRESS_DEBUG_LOG’ = TRUE then podPress writes status messages to a log file in the podPress folder. That makes it possible to look how far the duration and ID3 tag retrieval process goes. At the moment it does not log other things.
I have received another report via email. The duration and ID3 tag retrieval process may not work on every system probably because of exceeding of time and memory limits of the PHP configuration.

The message you get during the podPress activation is caused by a PHP warning (or a notice) and WP 3.0 notices that, captures the original warning and puts out an own warning message. The 2533 characters are very likely the length of the original warning (or notice) which probably says in which line of the code the problem exists.

I would try to look out for the original message.
One way is to add some lines to a WP file.

if ( FALSE === function_exists('error_get_last') ) {
			echo '<div id="message" class="error"><p>error_get_last() is not available</p></div>';
		} else {
			echo '<div id="message" class="error"><p>' . sprintf(__('error/warning/notice: <code>%s</code> | length: <code>%s</code>'), esc_html(var_export(error_get_last(), true)), $_GET['charsout']) . '</p></div>';
		}

Add these lines between line 344 and 345 of the plugins.php in the folder /wp-admin/ temporarily. It will put out the original message text below the WP message after an activation.
(Requirement is PHP 5.2.x – If you don’t have an older PHP version on your server then I will try find another way.)

Please post the original message here.

Thanks for the help. I inserted the code into plugins.php and it shows the original error msg now. The first time I re-upped the plugin it showed some error with google xml sitemap generator plugin so I disabled that. Now I think I am getting the actual problem:

error/warning/notice: array ( ‘type’ => 2048, ‘message’ => ‘is_a(): Deprecated. Please use the instanceof operator’, ‘file’ => ‘/usr/www/users/mysitefolder/wp/wp-includes/script-loader.php’, ‘line’ => 582, ) | length: 2533

Is this a deprecated function warning in podpress?

-Ray

By the way, with the google xml sitemap plugin (google-sitemap-generator) plugin activated the error msg thrown when podpress is activated becomes this:

error/warning/notice: array ( ‘type’ => 2048, ‘message’ => ‘Non-static method GoogleSitemapGeneratorLoader::GetBaseName() should not be called statically’, ‘file’ => ‘/usr/www/users/myusername/wp/wp-content/plugins/google-sitemap-generator/sitemap.php’, ‘line’ => 199, ) | length: 2533

The first message is because you are using PHP 5 and as I understand it, the way WP uses the is_a() function (https://www.php.net/manual/en/function.is-a.php) is apparently deprecated (‘instanceof’ is not in use). So this messages only related to podPress because podPress uses 8.8.5 the action hook wp_print_scripts to register, enqueue and print scripts to the frontend header.
But i have searched again and found a tutorial which uses the ‘init’ hook to do that. Maybe this hook is more appropriate to do all that. RC 2.1 (now available) uses this ‘init’ hook to register, enqueue and print scripts and styles to the front-end header.

The other message is obviously not related to podPress.

Using RC 2.1 now. Still get this error:

error/warning/notice: array ( ‘type’ => 2048, ‘message’ => ‘is_a(): Deprecated. Please use the instanceof operator’, ‘file’ => ‘/usr/www/users/myusername/wp/wp-includes/script-loader.php’, ‘line’ => 582, ) | length: 2533

I am running PHP 5.2.13

I’m going to take back the last change because it adds some script before the DOCTYPE line (to early) e.g. on the login page.

Furthermore I have searched through this WP.org forum for an explanation of the “[…] characters of unexpected output during activation. If you notice “headers already sent” […]”-message. But there are no solutions or explanations for the message, too.

But I have searched for more information about the

error/warning/notice: array ( 'type' => 2048, 'message' => 'is_a(): Deprecated. Please use the instanceof operator', 'file' => '/usr/www/users/myusername/wp/wp-includes/script-loader.php', 'line' => 582, ) | length: 2533

message.

The explanation of the message type (2048) suggests that the message is more a like suggestion than a report of a system breaking error. That is probably the reason why WP does not stop the activation of the plugin and says “[…] If you notice “headers already sent” messages […]” do something.

I have also tried define(‘WP_DEBUG’, true); in the wp-config.php and set error_reporting(E_ALL | E_STRICT); to see all PHP message. But I still could not reproduce the messages you have posted above.
The only messages I have recieved while having set these error reporting settings were messages about some things in the WP source code itself which I could fix with small changes in the WP code. (No other plugins have been active during the de-/reactivating of podPress)

WordPress itself produces with define(‘WP_DEBUG’, true); PHP Notices which can cause “Warning: Cannot modify header information” messages and break the page. For instance on the plugins page: I get in the debug mode always the notice “Notice: Undefined index: plugins in H:\xampp\htdocs\wp30mu\wp-admin\plugins.php on line 16” (whether plugins are activated or not). But this notice is only a notice for the developers which says basically that this line is a little bit sloppy $menu_perms[‘plugins’] is obviously not defined at this point of code execution:
line 16:

else if ( $menu_perms['plugins'] != 1 && is_super_admin() )

and with

else if ( isset($menu_perms['plugins']) && 1 != $menu_perms['plugins'] && is_super_admin() )

you can prevent the notice. isset() checks first whether the variable is defined.
But it is only a notice and the PHP interpreter can handle the “sloppy” line, too. That why WP works without problems while WP_DEBUG is not defined or defined as FALSE.
On the other hand the output of this notice can break the page on activation of a plugin because this notice is put out at a wrong moment during the page loading process and causes these “Warning: Cannot modify header ” warnings.

What I want to say is that you can should follow the WP message: “[…] If you notice “headers already sent” messages, problems with syndication feeds or other issues,[…]” report these messages which are probably “real” error messages here. But if you do not recognize such other messages you can use podPress.

You could also review your error_reporting settings. They are eventually a little bit to strict for the normal usage.
In normal blogs I set define(‘WP_DEBUG’, false); and error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_USER_DEPRECATED (resp. error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_USER_DEPRECATED);)

Or that this warning is caused under influence of another plugin.

Have you tried to deactivate all plugins and reactivate only podPress?
Does one of the messages appear?

I have noticed one other strange thing that I did not report earlier. If I navigate to my site without the www in the domain name I get the “cannot modify header” error on the main site page!

Warning: Cannot modify header information – headers already sent by (output started at /usr/www/users/mysite/wp/wp-content/plugins/podpress/podpress.php:438) in /usr/www/users/mysite/wp/wp-includes/pluggable.php on line 890

I have the “WordPress address” set to https://www.mysite.com/wp and the “Site address” set to https://www.mysite.com as we discussed earlier. When I load https://mysite.com in my browser I get the above error. When I load https://www.mysite.com – no error. This made me suspect the .htaccess file so I resaved the permalinks and it did not fix the problem. I removed everything in my .htaccess file except the following:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

# BEGIN podPress
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^feed/(.+)$ index.php?feed=$1
RewriteRule ^play/(.+)$ index.php?play=$1
RewriteRule ^web/(.+)$ index.php?web=$1
</IfModule>

# END podPress

The only other things that I can think of that are different from a vanilla WP install are that I am using custom permalink structure:

/%category%/%postname%/

and I am using podPress_iTunesLink(); in my sidebar but I tried disabling that and it makes no difference. If I deactivate podpress I can load my site with or without www and no “cannot modify header” errors. This is unfortunately a showstopper for me because my user pages will not load if the full url (including www) is not typed in…

By the way, yes, I have deactivated all other plugins and the same error appears when I activate podpress.

I wish you could tag the SVN repository. I don’t think previous versions had this problem but its non-trivial to rollback without tags.

Do you have downloads for various versions around? How about 8.8.5 beta 14.1? I am running that on another site with an identical setup and it doesn’t give the error message when I activate the plugin OR the “cannot modify headers” when I leave off the www…

I have made a roll-back to RC 2 which should solve the new problem which you have described in your last post (two lines in the podpress.php). As I have mentioned in my last post the changes (two lines) from RC 2 to RC 2.1 let WP print out the some script at the wrong time. Furthermore I rolled back some other changes to beta 14.1 (in the podpress_functions.php). Although I doubt that rolling back these lines in the podpress_functions.php make any difference. But one can never know… I’m sure that all other changes from beta 14.1 to RC 2 can not cause the message on the plugins page.

I’m sorry that you run every time you test into trouble! But some changes I have made are based on assumptions since I’m unable to reproduce the situations you describe.
BTW: You can get a good overview of the changes here: https://plugins.trac.www.ads-software.com/log/podpress/

Do you have downloads for various versions around? How about 8.8.5 beta 14.1? I am running that on another site with an identical setup and it doesn’t give the error message when I activate the plugin OR the “cannot modify headers” when I leave off the https://www…

That is really interesting and of course it looks like the two problems are related to the changes which I have made since beta 14.1.
If the RC 2.2 does not help and if you are absolutely sure that the PHP settings on the other site you have mentioned are the same, I’m going to make complete roll-back to beta 14.1 and add the changes in smaller steps. That should make it possible to narrow the problem down to its origin. The changes I have between these two version are important for the general usage of podPress and debugging other problems. That is why I don’t want to throw them away.

Please, save the files of the podPress beta 14.1 from the other site and test RC 2.2 there, too if RC 2.2 does not make such trouble on your first site.

btw: I’m using a TortoiseSVN client to check out versions from the SVN server. ith this client it is possible checkout a specific revision of podPress from the WP repository as well. I’m sure that there is a way to do that with Linux or Mac SVN clients, too. The revision of beta 14.1 is 257945. You can get the other revision numbers here: https://plugins.trac.www.ads-software.com/log/podpress

If you want to test with older versions then I would recommend RC 1.1 (Rev. 262179) because I have added a new function and the new constant from RC 1.1 to RC 2. It is more unlikely that the changes from beta 14.1 to RC 1.1 can produce the message on the plugins page.

Good morning. I just checked out the latest (RC2.2 shows in admin panel) and it does fix the cannot modify headers problem when loading the url without www – thank you. I still see the error msg in the admin panel when activating the plugin.

You are probably right that I can check out versions by rev. number instead of tag. I am using svn propedit svn:externals to include plugins in my wp-content/plugins folder and I don’t know the syntax for checking out specific revisions of externals. But I can check it out somewhere else and copy it over.

I will test with my second site today and make sure that RC2.2 throws the same error on that site. Stay tuned.

By the way, thank you *very* much for the excellent support for this plugin.

-Ray

OK. I have done some further testing with a second site and I need to clarify the situation so I am not sending you down rabbit trails based on bad info.

Using current svn trunk (rev. 263572) podpress plugin works well but shows an error msg in the admin console whenever it is activated in WP 3.0. In WP 2.9.2 there is no error msg in the admin console. It is WP version specific.

When I rolled back to podpress beta 14.1 the error msg is still there. It is not related to the podpress code changes as I previously reported, sorry. I was using WP 2.9.2 on the second site that’s why the error msg did not appear. I thought it was not there because it was using podpress beta 14.1 but after I upgraded the site to WP 3.0 the error appeared in the admin console when activating the plugin (either version).

The two different sites behave identically except that the length of the unexpected output is slightly different:

The plugin generated 2461 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.

vs.

The plugin generated 2533 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.

The problem with “headers already sent” has been fixed in the latest podpress (rev. 263572) and does not occur in beta 14.1.

I hope this info helps. Please let me know if I can test anything for you on this server. I appreciate all your effort in taming this wild beast of a plugin for WP 3.x

-Ray
FreeBSD 7.2-STABLE
WP 3.0
PHP 5.2.13
MySQL 5.0.67

Thank you for the additional test and the clarification! Yes, it is helping.

But I still don’t know what causes these messages like “The plugin generated x characters of unexpected output during activation. …”.

Yesterday, I tested a lot with these error_reporting settings of my PHP installation and the WP_DEBUG constant and I have to say that if I turn all reporting settings on then I get a comparable message in the admin console (one with 1190 characters).

But when I activate an other plugin which has widgets and an option page in the site admin (admin console) then I don’t get such a message. So there is something in podPress which is not as it should be.

I’m going to investigate this further. But for the moment I’m convinced that it is ok to follow the message literally. Since it is only visible when you(I) turn on all error_reporting settings and since it seems to be only some kind of notice and not a PHP error.

I think causes can be the way podPress sets back some of its settings on reactivation or the usage of the old Widget API (It is only possible to use the widgets only once in one blog.)
or that somewhere in the podPress code is a PHP function which was marked as deprecated in modern PHP versions.

It has probably something to do with the (re)activation process because it seems that there are no other messages or errors in other situations (omly on the plugins page in site admin during reactivation).

I will report back later.

I agree that it seems to be a warning that can be ignored without problms but remember that it is WP version specific whether this error shows. So something is changing between WP2.9.2 and WP3.0 that triggers this.

-Ray

Good news! I have used a function like the new podpress_var_dump() (podpress_admin_functions.php:1271) to write all the messages which are filtered by WP 3.0 during a plugin activation to a log file. I recieved not only the last one as before with the help of the other tweak in the plugins.php.
If some one likes to do a similar thing, print the content of $result->get_error_data in line 63 of the /wp-admin/plugins.php (WP 3.0) and you will get not only the length of the notices and E_DEPRECATED messages.

In the end I could fix all the things which caused the messages (at least on my test systems). How is it with the 8.8.5 RC 2.3 on your system (Ray)?

Regards,
Tim

BTW: The trigger resp. the cause for the messages was partially in the plugin since 8.8 but WP 3.0 started to filter these notices and E_DEPRECATED messages and to display own messages. That these non-error messages show up depends on the PHP version and the PHP error_reporting settings, too.