Fatal error: Call to a member function get_page_permastruct() on a non-object in /home/omry/dev/php/wp/2.6/wp-includes/link-template.php on line 152

[omry]

get_permalink($id), where $id is the id of a page, generates a fatal error:

Fatal error: Call to a member function get_page_permastruct() on a non-object in /home/omry/dev/php/wp/2.6/wp-includes/link-template.php on line 152

same call works correctly when the id is the of a post.

[omry]

btw: $wp_rewrite is NULL when this errors.

[mrmist]

Can't seem to reproduce this through use in a template (no matter what I pass to the function, and regardless of permalink settings.)

<p><?php echo get_permalink($id); ?></p>

Works for me.

How are you using it?

[omry]

in a callback from my plugin. it's not in a context of a template.

try in a plugin initialization code.

[DD32]

Some example code might help understand it a bit clearer?

$wp_rewrite is defined on line 515 of wp-settings, Which is before the init hook is called, So your plugin *most probably* shouldn't be calling that set of functions yet anyway(Assuming you're using plugins_loaded or sanitize_comment_cookies hooks)

[omry]

okay, I`ll provide a test case.

[omry]

Providing a test case is tricker than I thought.
instead, here is a full stack trace of the error.
this happens if I try to get the get_permalink($id) on an id of a page.
if I do it on an id of a post, it always works.

Fatal error: Call to a member function get_page_permastruct() on a non-object in /home/omry/dev/php/wp/2.6/wp-includes/link-template.php on line 152

1	0.0004	125404	{main}( )	../index.php:0
2	0.0007	171344	require_once( '/home/omry/dev/php/wp/2.6/wp-admin/admin.php' )	../index.php:3
3	0.0008	181856	require_once( '/home/omry/dev/php/wp/2.6/wp-load.php' )	../admin.php:7
4	0.0009	187688	require_once( '/home/omry/dev/php/wp/2.6/wp-config.php' )	../wp-load.php:27
5	0.0019	347640	require_once( '/home/omry/dev/php/wp/2.6/wp-settings.php' )	../wp-config.php:20
6	0.0645	8710472	include_once( '/home/omry/dev/php/wp/2.6/wp-content/plugins/firestats/firestats-wordpress.php' )	../wp-settings.php:421
7	0.0795	10444120	require_once( '/home/omry/dev/php/wp/2.6/wp-content/plugins/firestats/php/ajax-handler.php' )	../firestats-wordpress.php:31
8	0.0931	12308816	fs_ajax_update_wordpress_titles( )	../ajax-handler.php:151
9	0.0931	12308884	fs_update_post_titles( )	../ajax-handler.php:195
10	0.0970	12700012	get_permalink( )	../firestats-wordpress.php:1247
11	0.0975	12730668	get_page_link( )	../link-template.php:66
12	0.0976	12730828	_get_page_link( )

[omry]

btw:
I know the stack trace seems a bit crazy.
I have a very good reason to do what I do the way I do it.

[jacobsantos]

Dude, I feel like downloading your plugin and showing you exactly where you are screwing up. However, I don't think I should support your plugin, when I don't have the time to support my own.

[jacobsantos]

Replying to jacobsantos:

Dude, I feel like downloading your plugin and showing you exactly where you are screwing up. However, I don't think I should support your plugin, when I don't have the time to support my own.

What I mean to say is that this is most likely invalid, but I don't want to spend the time to prove it.

[omry]

jacobsantos, I am screwing up is where I call get_permalink($id) in a specific context, and if fails if the id is a page and works if it's a post?

if you insist on getting a test case, I can provide one with a bit of effort. but I am sure this inconsistent behavior from WP is a bug.

[jacobsantos]

I talking about $wp_rewrite global being null, meaning that the function is being called before the global is created and set up to the WP_Query class. If it is working for a post and not a page, then that seems to be a separate and valid issue.

As for the test cases, I might help you with those. You're going to need one for WP_Rewrite::get_page_permastruct() for both posts and pages. Several for _get_page_link(), which has the global set up. It would be better if they were unit tests, because you're going to have to destroy the global and set it up for each test. That is going to adversely affect the other test cases.

The test suite is going to save the state of the $wp_rewrite before the test cases and then restore it after the test case.

[omry]

here is a pretty minimal test case that demonstrates the problem.
it's nothing as fancy as you asked, but it's easy enough to use.

in it's present form, the plugin will activate successfully. if you will comment the 'works' line and uncomment the 'fails' line the plugin will fail to activate.

<?php
/*
Plugin Name: Page permabug plugin
Plugin URI: bogus.org
Description: The bogus plugin from hell
Author: Ya
Version: 666.6
Author URI: nope.org
*/

fs_update_post_titles("post");  // works
#fs_update_post_titles("page"); // fails


function fs_update_post_titles($type)
{
    global $wpdb;
    $posts = $wpdb->get_results("SELECT ID,post_title FROM $wpdb->posts WHERE post_type = '$type'");

    foreach($posts as $post)
    {
        $id = $post->ID;
        $title = $post->post_title;
        $link = get_permalink($id);
    }
}
?>

[omry]

you will probably need to have permalinks enabled, of course.

[DD32]

And i have to say running code as soon as the plugin is included is a bad choice, WordPress hasnt fully initialised at that point, Theres a fair bit of setup which is required after the plugins are included, And if you require access to Permalinks, You'll need to have your code run when the permalink code initialisation has been done.

I'm not going to test it straight away, but is there any reason why you cant use this?

add_action('init', 'fs_update_post_titles_post');
add_action('init', 'fs_update_post_titles_page');

function fs_update_post_titles_post(){ fs_update_post_titles("post") };
function fs_update_post_titles_page(){ fs_update_post_titles("page") };

[omry]

actually there is a reason, but it's complicated and not really relevant to the bug.

if you really want to know I can explain, but it wont help with the bug.

[westi]

You can't rely on WordPress core functions all being available until the init hook fires.

That plugin is bogus.

Marking as INVALID.

[omry]

nice solution.
+1.