jbauguss

another solution is to put this in your footer right above </body></html>

<script type=”text/javascript”>
tb_pathToImage = “/wp-includes/js/thickbox/loadingAnimation.gif”;
tb_closeImage = “/wp-includes/js/thickbox/tb-close.png”;
</script>

this will avoid having to use cpu to do the rewrite method (which is a fine solution tho)

The problem you are having is that wordpress’s version of thickbox is being included. That version however is specifically coded for the admin side of the site. While it can be used easily for front end stuff, it has this nasty side effect.

If you don’t want to add that to your footer, just edit thickbox.js in wp-includes/js/thickbox. problem there tho is new versions of wordpress will overwrite your change. Best to just add this to footer.php of your theme.

bump… no reply.. another patch came out without this fix. Yet again I had to refix sites using ssl. Please fix this. I’ve even given you the code.

well, there are problems with relying on the default templates for custom content. Biggest problem is the loop. Most themes will have the loop followed by a handler for if no posts/page were found (if(have_posts) fails) so while you could attach something before or after the loop via a plugin hook, you would end up with your content and then a not found message. I think offering a custom template is pretty much a must.

the only option i can think of other than that is to simulate a post by making use of the query hooks and creating a post object so the loop can find something. Not sure I can really help much there as I’ve never tried that.

oh, another option….I just did this actually. just use a content filter. Have your plugin rely on the creation of a page or post with a custom tag in it like {replaceme} and you can replace that tag with your custom content. You then let them rely on the page/post templates as well as the freedom to name the page what they want and surround the custom content with whatever they want.

One thing to note. Unless you are planning on using filters for the post query, the page template won’t know what to do. It relies on having a post query run.

I’m doing something similar but my template_redirect loads a template that doesn’t rely on posts/pages. I lookup my own data in a different table not related to wordpress. therefore, using a template like page.php that relies on the loop will result in a whole lot of nothing (since no blog pages/posts were looked up)

example for your hello world.
function dopage () {
include(TEMPLATEPATH . “/dopage.php”);
exit;
}

make dopage.php in the template dir with this content
<?php get_header();?>
hello world
<?php get_footer();?>

i think that would work. Basically, what would happen is, wp is gonna look at the url, sees wp from /wp/?test=1 will recognize wp as a page or category. this results in a 404. when your template_redirect runs, you intercept by looking at test= and use a different template.

another way to handle the url can be learned from Custom Query Page

at the bottom of that page are 2 real important sections. Custom Archives and Permalink to Custom Archives.

i hope this helps.

also, i think this is more efficient. I got this tidbit from jerome’s tag keyword plugin.

in an init function for your plugin (make sure to hook it in)

global $wp_redirect;
if(isset($wp_redirect))
add_action(‘generate_rewrite_rules’, ‘myrewriterulefunction’);

doing that i think ensures that it only runs when necessary. (on the permalink option page) Otherwise you run the risk of updating the permalinks every page load which would be bad.

I think I understand that right at least.

well, I just went through a day of trying to figure this out. I finally had my eureka moment.

the BIG thing you are missing. You must let wordpress know about your query variables or it will not grab them.

add_action(‘query_vars’, ‘yourqueryaddfunction’);

function yourqueryaddfunction($qvars) {
$qvars[] = ‘network’;
return $qvars;
}

and per your code above, you would need add_action(‘template_redirect’,’miljo_redirect’);
to be
add_action(‘template_redirect’,’netwrok_redirect’);

not sure if you had some typos or just cut and paste issues.

well, i don’t have an answer right now. But wordpress + plugins is a memory nightmare.

A quick test from a blog not even live yet. I’ve got cforms, podpress, syndicate and a couple custom plugins enabled.

The real culprit behind wordpress memory issue looks to be the options table. WordPress immediately loads all options into a global options array. (just put die(print_r($GLOBALS)) in an init hook of a plugin)

So i did the following test.

index.php i did an echo memory_get_usage();
then in my init hook of a custom plugin I repeated the echo and then threw a die() so I would see the results.

Before wordpress starts. php prints ~50kb of memory used. after the init is done, php is using 10mb of memory!

Now this is with those plugins setup. I’ve got 5 forms setup in cforms. It looks like a design problem in the allowed usage of the options table. cform puts all its configured tables into the options table. This is really bad. While it might be ok for a site with very little traffic, its death if you get any decent traffic.

Also keep in mind, that was just in the init hook. wordpress hadn’t even looked up categories and posts yet.

If none of these cache plugins takeover before wordpress loads options, then they won’t save any memory.

To harp a little more on the memory. That means php will load 10mb+ of memory into the apache process. I’m not gonna go deep into apache processes, but if you have high traffic, you might have over 80 processes running for apache. Each “live” process will expand its memory need and keep that memory until it dies. so if php demands more memory, that process will keep that memory for its life cycle.

I’ll be looking into this in the coming weeks as I have a new client who gets 50k hits a day on his blog and this memory issues is really killing his server.

some more tests to run would be a default wp install and see what its base memory needs are. I really am beginning to feel that the wordpress devs should start educating their users on this. They could curve some of this by guiding plugin authors to not use the options table and keep their own options in their own table and not to load them in globals.

Wanted to share these finds with you.

best of luck, I’ll try and remember to post my findings if I can solve this.