• I’m debugging an old aggregator plugin (BDP RSS) so that it will work with WordPress 3.x, but it seems like something squirrely is going on with our session data. Specifically, we are submitting a form where the action on the submit is pointing to the same PHP page. The data is filled in on the form. However, when viewing the $_POST array after the submit, it is empty. We aren’t sure what could cause the session data to get lost.

    Here’s a critical piece of code:

    /* ----- Capture and process form variables ----- */
    
    error_log("in bdp-rssadmin 1");
    print_r($_POST);
    
    if( isset($_POST['bdprss_add_feed_button']) )
    {
    	error_log("in bdp-rssadmin 2 - inside IF statement");
    	$r = bdpSetFeed($_POST['bdprss_new_feed_name']);
    
    	if($r) echo $r;
    
    }

    The statements error_log("in bdp-rssadmin 1"); and error_log("in bdp-rssadmin 2 - inside IF statement"); are being used to debug this. In our error log, we can see that it’s making it through the first statement, but not the second, and that would seem to indicate what we know already: that the $_POST array is empty (i.e. not being set). As an fyi, we’re using the print_r($_POST); statement to print the contents of that array to the screen, but it’s always empty.

    Any thoughts?

Viewing 9 replies - 1 through 9 (of 9 total)
  • Might be a stupid question but is the form’s submit method set to POST?

    Thread Starter LanceGrigsby

    (@lancegrigsby)

    Yep, sure is:

    <form method="post" action="<?php echo $selfreference; ?>">

    So, in looking further, I investigated the construction of the $selfreference variable. It looks like this:

    $selfreference = get_settings('siteurl') . '/wp-admin/edit.php?page=' .BDPRSS2_DIRECTORY. '/bdp-rssadmin.php';

    … and now, I’m really curious as to why it’s using edit.php and wondering if that’s where the problem is. In version 3, edit.php is including ../admin.php at the very top, and through debugging, I’ve figured out that something is not making it through admin.php.

    If this is ann admin area page then I think the $selfreference is wrong (or just obsolete), my plugin pages’ URLs are like ‘/wp-admin/admin.php?page=plugin_page_slug’ where the slug is set when the plugin creates the menu.

    The simplest way to check this is to open this form in a browser, copy the URL and paste it into the form’s ‘action’. If it works this hard-coded way, then the URL creation iis wrong.

    Thread Starter LanceGrigsby

    (@lancegrigsby)

    Molnarm, you are spot on! Thanks a lot. I did exactly as you suggested, and it worked perfectly. Now the issue is this: Even when I change the $selfreference variable as listed above to go to tools.php instead of edit.php, it only works over ssl, but siteurl uses https:// and not https://. This problem is described here. However, I just learned that siteurl has been deprecated in favor of home_url. So, by rewriting the aforementioned $selfreferencevariable to …

    $selfreference = get_settings('home_url') . '/wp-admin/tools.php?page=' .BDPRSS2_DIRECTORY. '/bdp-rssadmin.php';

    … it seems to work like a champ. Thanks for the lead!

    Thread Starter LanceGrigsby

    (@lancegrigsby)

    molnarm, next problem: This is working great for the admin, but for a child site–not so much. Using a regular user account, attempting to submit form data routes me to the dashboard. Ugh. Gotta be a permissions problem.

    Thread Starter LanceGrigsby

    (@lancegrigsby)

    Here’s the exact problem: In a child site account in a multisite environment using the exact same form, I get routed to …

    https://servername.host.com/childsite/wp-admin/?c=1

    … when I submit the form data. I’m seeing that home_url could also be get_home_url or network_site_url according to this documenation, but I tried using those instead but no luck.

    Hi! Glad to hear that your first problem is solved.

    I checked this plugin, it was last updated in 2006 or so. If you’re really determined to use this instead of finding a newer one, I recommend going through its code to fix any deprecated calls or constants. It’s not that huge and you may have more chance to make it work with a systematic approach instead of hunting down random bugs.

    “Ugh. Gotta be a permissions problem.”

    For example, it creates the admin menu with add_management_page, but with only 3 argument so the capability required to see the page is omitted. I haven’t found any default value for this so this might be a problem too.

    Thread Starter LanceGrigsby

    (@lancegrigsby)

    Molnarm, thanks for staying on the case. The appeal of this plugin was that it allowed you to aggregate more than one RSS feed in a sidebar widget. If you know of any new ones that do the same thing, I’d love to hear about it. Yahoo Pipes would do the trick with the native WP RSS widget, but Pipes supports only up to 10 feeds at a time. That said, I’ll give the “systematic” approach a shot and see how it goes. If nothing else, it’ll force me to learn more PHP.

    Thread Starter LanceGrigsby

    (@lancegrigsby)

    Second hurdle cleared: Form submission is now working for child-site admins now. Same issue as before. I just had to find a way to weed out all the deprecated code in the $selfreference variable so that the submitted data had a correct https URL to submit to.

    So, $selfreference originally looked like this:

    $selfreference = get_settings('siteurl') . '/wp-admin/edit.php?page=' .BDPRSS2_DIRECTORY. '/bdp-rssadmin.php';

    The revised code looks like this now:

    $selfreference = home_url('/wp-admin/tools.php?page=' .BDPRSS2_DIRECTORY. '/bdp-rssadmin.php', 'https');

    Since the get_settings function is now deprecated and the siteurl tag is incapable of passing along https, I decided to use the home_url function and its path and string parameters, respectively, the append the proper URL and specify that it should be https. I wish I were knowledgeable enough to address your comment about the use/misuse of add_management_page, but this seems to be working for now … on to other bugs :).

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘What's happening to my session data? Help!’ is closed to new replies.