WordPress.org

Ready to get started?Download WordPress

Forums

podPress
[resolved] 8.8.5 RC unexpected output error on initialization (25 posts)

  1. raymer
    Member
    Posted 4 years ago #

    I have installed the podpress 8.8.5 svn trunk on two domains running WP 3.0. In each case whenever I activate the plugin from the plugins page I get this error msg at the top of the admin page.

    Plugins Add New
    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.

    This msg occurs everytime I deactivate/reactivate podpress. It has remained since sometime in the 8.8.5 betas until now.

    I noticed a new 'PODPRESS_DEBUG_LOG' constant in RC2 and I got it working on my system. Can you explain what I should dump to get a clue as to what unexpected output might be causing this?

    Both domains are running on FreeBSD on a shared hosting server and I have ssh access. Podpress seems to be working well and I'd like to get to the bottom of this error msg so I can start using the plugin on other sites.

    Thanks,
    Ray

  2. ntm
    Member
    Plugin Author

    Posted 4 years ago #

    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.

  3. raymer
    Member
    Posted 4 years ago #

    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

  4. raymer
    Member
    Posted 4 years ago #

    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

  5. ntm
    Member
    Plugin Author

    Posted 4 years ago #

    The first message is because you are using PHP 5 and as I understand it, the way WP uses the is_a() function (http://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.

  6. raymer
    Member
    Posted 4 years ago #

    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

  7. ntm
    Member
    Plugin Author

    Posted 4 years ago #

    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?

  8. raymer
    Member
    Posted 4 years ago #

    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 http://www.mysite.com/wp and the "Site address" set to http://www.mysite.com as we discussed earlier. When I load http://mysite.com in my browser I get the above error. When I load http://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.

  9. raymer
    Member
    Posted 4 years ago #

    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 http://www...

  10. ntm
    Member
    Plugin Author

    Posted 4 years ago #

    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: http://plugins.trac.wordpress.org/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 http://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.

  11. ntm
    Member
    Plugin Author

    Posted 4 years ago #

    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: http://plugins.trac.wordpress.org/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.

  12. raymer
    Member
    Posted 4 years ago #

    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

  13. raymer
    Member
    Posted 4 years ago #

    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

  14. ntm
    Member
    Plugin Author

    Posted 3 years ago #

    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.

  15. raymer
    Member
    Posted 3 years ago #

    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

  16. ntm
    Member
    Plugin Author

    Posted 3 years ago #

    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.

  17. raymer
    Member
    Posted 3 years ago #

    @Tim,
    I was disappointed because RC 2.3 still shows the warning on initialization. But after looking around more on Google I think I finally understand what is going on and I am pretty certain this warning can and should be ignored. After reading this post:
    http://wordpress.org/support/topic/318452?replies=9
    I am now pretty sure that the error is showing because I am using PHP 5.2.13. The is_a() function was deprecated in PHP 5.0 and then as of 5.3 it was no longer deprecated (!)
    http://php.net/manual/en/function.is-a.php

    I think the WP developers removed is_a() from WP in 2.9.2 and then started using it again in WP 3.0 because it was no longer deprecated. So when my webhost upgrades to PHP 5.3+ the message should go away!

    The only think I can't understand is why podpress is the only plugin I have that throws this error. I have over 10 other plugins active and podpress is the only one that does this. But I'm sure brighter minds than me can explain it :-)

    Once again, thank you for your tireless work in keeping podpress alive and now I believe it is more stable than it has ever been. You should consider reposting your method of getting detailed error info in WP 3.0 as a separate post in the appropriate plugin developer section. I'm sure other plugin developers would benefit from it.

    -Ray

  18. raymer
    Member
    Posted 3 years ago #

    @Tim,
    Oops I just re-read your BTW on your last post and realize that the trigger you were describing in the plugin is probably why that error was being passed up only on podpress. Anyway, I still don't understand the podpress source code but I'm now confident (thanks to you) that this particular error msg is not an issue.

    -Ray

  19. ntm
    Member
    Plugin Author

    Posted 3 years ago #

    Hi Ray,

    I'm using PHP 5.3 as part of XAMPP 1.7.3 on my main test system and PHP 5.2.9 on the real server (undeuxoutrois.de/wp). I get no messages during the reactivation of podPress on both systems.

    But the status of the is_a() function in different PHP versions probably explains it. On the other hand messages on the plugins page may originate from themes. For instance the K2 theme (v1.0.3) uses obviously some inappropriate formulations. I had to switch to the new Twenty Ten to get only the messages of podPress.

    That you are still getting messages is to bad. Maybe it is ok to ignore them but the messages I have got were no PHP errors but errors which made the plugin work not correctly. So I would like to know whether there are more notices besides this is_a()-message (which can be ignored) on your system or not.
    In order to find that out: Could you please install and activate temporarily a little plugin which I called Print PHP Notices?
    Basically it is the function I have mentioned above. It prints all messages to log file.
    Could you please post these messages here?

    You can download this plugin here.

    Motivation:
    If you run WP 3.0 and you get messages like "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." then you can uses this plugin to print the original messages which have e.g. 2533 characters into a log file. (These messages might occur if you set the constant WP_DEBUG = TRUE.)

    Usage:

    • use ONLY with WP 3.0 (upcoming WP version might have build in such output function (see this proposition))
    • install and activate this plugin
    • insert in line 63 of /wp-admin/plugins.php the lines:
      if (function_exists("printphpnotices_var_dump")) {
      						printphpnotices_var_dump($result->get_error_data());
      					}
    • (re-)activate the other plugin which causes the messages
    • look into the log file (printphpnotices_log.dat) which is in the folder of Print PHP Notices plugin

    What basically is in this tiny plugin:

    if ( ! defined( 'PRINTPHPNOTICES_DIR' ) ) { define( 'PRINTPHPNOTICES_DIR', WP_PLUGIN_DIR.'/'.dirname(plugin_basename(__FILE__)) ); }
    
    function printphpnotices_var_dump($var) {
    	// write the out put to the log file
    	$filename = PRINTPHPNOTICES_DIR.'/printphpnotices_log.dat';
    	if (is_file($filename)) {
    		chmod ($filename, 0777);
    		if ((filesize($filename)/1024) > 100) { unlink($filename); } // delete the Logfile if it is bigger than 100 kByte
    	}
    	$handle = fopen($filename, "a");
    	fputs($handle, var_export($var, TRUE)."\n");
    	$status = fclose($handle);
    	if (is_file($filename)) {chmod ($filename, 0644);}
    }
  20. raymer
    Member
    Posted 3 years ago #

    Hi Tim,
    I installed the plugin and added the code. I think it helped me understand the problem. It is a permissions issue. My shared hosting server runs apache as a different user than my username and it does not have write permissions for the plugins dir. But in podpress_functions.php starting on line 887 the plugin tried to create a custom file for the XSPF_skin_file. These file writes and chmods are failing and that is what is triggering the errors. I haven't been using the XSPF player so I haven't noticed a problem with functionality but it looks like this file is created on plugin initialization if it is not present...

    Send me your email and I will mail you the error log file privately so I don't expose my server info publically.

    Thanks,
    Ray
    ray (AT) raymercer.net

  21. ntm
    Member
    Plugin Author

    Posted 3 years ago #

    Hello Ray,

    Thank you for the log file!
    The messages are clear and your explanation with the different permissions of the different user(name)s sounds very reasonable.

    I have revised or more correct removed the function which tried to rewrite the XSPF skin file on plugin activation. I have made this function originally to recreate the old XSPF skin file after an automatic plugin upgrade. One way to define the width of the XSPF player is via the widgets settings. When you save the settings all width measures in the skin file will be changed and the file rewritten. But with an automatic plugin upgrade all old files are lost and the default skin file from the repository is made width the default width.

    Now, the consequence is that you need to save the XSPF player widgets settings manually after an automatic upgrade. I think this acceptable because it will be relevant for the first time with the next plugin version and maybe podPress 8.8.6 will have an improved version of this function which will also work on "Network Activate" in a multi site blogs.
    But until than I have to research some things which could take some time and it is probably more important to release 8.8.5 sooner than later.

    I have added to RC 3 also an additional custom error message which shows up when you try to save the XSPF player width in the widgets settings manually and you have not the permission to use chmod().

    Regards,
    Tim

  22. raymer
    Member
    Posted 3 years ago #

    Hi Tim,
    This fixed it! I will mark this topic resolved because this has solved the original issue. I think showing a custom error msg is a good way to handle the permissions issue because then I can decide if I want to manually create the necessary file and give the webserver/PHP write permission for that file. This is how most plugins I have used work (for instance I had to manually give write permissions to the debug log plugin so it could create/write to that file).

    I plan to start using the XSPF widget on some sites in the future so I can tet it for you then.

    -Ray

  23. johngorenfeld
    Member
    Posted 3 years ago #

    I'm running that version of Podpress on WP3.0.1 and having problems getting it to work in single post view. Think it too is a permission problem, maybe?

  24. raymer
    Member
    Posted 3 years ago #

    @John - what problems are you experiencing? If you are experiencing problems with the auto-detect size or length that might be permissions. A couple of versions had the PODPRESS_DEBUG_LOG variable in podpress.php set to TRUE and that caused podpress to try to create a logfile in the podpress directory. My server runs apache under a different username and since my podpress dir is not world-writable it caused problems. I recommend you dl and try the latest dev version (which at the moment is 8.8.6 beta 1) here:
    http://downloads.wordpress.org/plugin/podpress.zip

    Tim has been fixing lots of bugs and the dev version works well for me. If you prefer to keep the version you are using, open up podpress.php and change the PODPRESS_DEBUG_LOG variable to FALSE. If that is not the problem post more details and I'll try to help.

    -Ray

  25. raymer
    Member
    Posted 3 years ago #

    @John, I just read your other post and it doesn't seem like a permissions problem. It looks like Tim understands your issue but can't reproduce it. In that case it is important to give him as many details as possible. Your WP version is 3.0.1 but what version of podpress are you using and what settings to you have - especially in the general page. Here are the settings I use and it works well:
    http://www.raymercer.net/downloads/podpress-screencap.gif

    But post the info in the other thread. I don't think its related to this resolved issue...

    Regards,
    Ray

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic

Tags