I'm working with a client who is wrapping the body of our WordPress site with their own external header and footer, stripping out our header and footer. Our enqueued plugin scripts then, aren't working because our header and footer aren't used at all. Also, it seems to me that NO plugins would work if they're not using our header/footer (not just the ones we've enqueued in functions.php). Is that true?

THIS DOESN'T WORK - YOU CAN SKIP IT UNLESS YOU JUST WANT TO READ IT. I talked with some smart folks at our Meetup about it, and they said I could print the scripts using the snippet below in my functions and they would then work again (mostly, but that this is a wonky work around). I've tried this, and so far it doesn't seem to be working. I would like to know why this should work - what does it do? If I understood it better, maybe I could figure out what is wrong.

function enqueue_scripts_the_wrong_way() {
    printf( '<script src="%s/js/jquery.stellar.init.js" data-load-script="1"></script>', get_stylesheet_directory_uri() );
add_action( 'wp_footer_print_scripts', 'enqueue_scripts_the_wrong_way' );

WHY DO THIS ANYWAY? @norcross asked on Twitter if I would explain why the client needs this in the first place. It might be helpful to know I was only contracted to design/develop the WP theme I'll talk about. The client has an existing website, parts of which used a WP site (for their blog), and parts of which use a custom CMS. They are essentially a small business social network, and that site has a lot of dynamic content based on the user's logged in/logged out status, and that passes around user's info. They wanted to move the more static parts of that website, and the blog, entirely to one WordPress installation so the marketing dept could better manage it (apparently the custom CMS is a pain). BUT, the header and footer on the website contains some of that logged in/logged out context. I told them that WP could get their external user database and work with it, but that's more than I personally know how to do - however I know lots of devs who DO, and that when the time came, I would make the right introductions. They said it wouldn't be necessary because they could wrap the WP content with their header and footer, since essentially all they wanted from the WP install was the content. They have some folks who are familiar with WP working on the project, so I assumed that however they were doing this, they would know that they had to somehow maintain the integrity of the WP header and footer, but I was wrong. What we've ended up with is well, exactly what they said, their header and footer with our body content. The WP install does have the header and footer with the wp_head and wp_footer calls in it (that's all, though), but however their wrapper works, it's not using them.

2 Answers 2


First, you are correct, many plugins will fail if the header and footer hooks are removed. What your client is doing is going to be very problematic-- dare I say "wrong"? That strips out a lot of functionality. If fact, there are limited dependable hooks on the front end and many are associated with the head and the foot.

Second, the snippet you have won't work because that is a footer hook and the footer has been removed.

I don't honestly see many good options for you. You can't echo stylesheets after </head> or you get invalid markup (which usually still works) so most hacks to include stylesheets are going to be dicey. By hacks I mean "put do_action('wp_enqueue_scripts') and other required hook calls in your code after the point at which your code executes.

Otherwise, you will need to depend on inline styles and probably hack plugins on a case by case basis to force them to work in your very broken environment.


If you do not care about the markup, you got a relatively simple way of offering your Plugins to use the right hook.

Usually, you call get_header() and get_footer() in your theme, and the associated files header.php and footer.php have to call the functions wp_head() and wp_footer().

They also contain, of course, Markup and the <head> section and everything.

If you can just deliver a content-section, the markup will become invalid, however, not necessarily broken.

You could try to create your page template like this:

<?php wp_head(); ?>

    <div id="yourdelivereddivwithoutheaderandfooter">...</div>

<?php wp_footer(); ?>

Keep in mind that you have to unhook a lot of filters that plugin run on wp_head in order to get it work right, but this may be your simplest shot.

  • I'm only partially following this approach - bear with me, I'll get it. But I have a question (maybe for @fischi and @s_ha_dum) . Would either of these approaches make it so that they wouldn't have to modify future plugins going forward? It sounds like I would make mods to existing plugins NOW, but what about after I'm out of the picture? Seems like they have low probability of repo plugins or purchased plugins working in this environment w/o mods to plugins. This (environment, not your solutions) feels BAAAADDDD. Commented Mar 4, 2014 at 19:49
  • Yeah, the environment is not perfect. But I think the best you can do is to use wp_head and wp_footer to ensure future plugin compatibility, as most plugins rely on the call of these two functions, not an actual HTML-Header being sent out. You have to be very careful tough and test everything a lot.
    – fischi
    Commented Mar 4, 2014 at 19:56
  • The dev on the client site has suggested, "as a way for you to tell me which scripts to include in the wrapper, you could add meta tags to the template that look something like <meta rel="wp-wrap-js" value="/path/to/script.js" /> then I could make sure I include those in the wrapper and if it needed to be in the head for some reason, we could add an attribute that tells me which section to put it in." I don't think that will work, either. Commented Mar 4, 2014 at 21:51
  • Wow, that's tough. You would have to rewrite the method that prints the scripts to output the metatags... Anyway, you have to compromize a lot here. You will have to work on a solution together with the dev team. On the WordPress side, we can help you achieve your goal, but you will have to ask specific questions, when you know how you want things to be done on your side. That's all I can help with the information provided :-/ hope you get it running!
    – fischi
    Commented Mar 4, 2014 at 21:58
  • Ok, here is the most specific question I think can ask at this point. Do you think there is a solution to this that would ensure they don't have to modify future plugins to comply with that solution? Commented Mar 5, 2014 at 18:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.