Erikvona

Yes, check this support forum post for an answer.

Yes. See this or this support thread.

Future support for custom post types is still in my to-do list, but for now I have other priorities.

Hey Yannick,

This typically happens when you add invalid HTML to the head section.
As far as I know, the plugin works under WordPress 4.0, and I have it running myself under multiple WordPress 4.0 sites.

You could try running your site through a HTML Validator? Or give me a link to your site? It could be as simple as forgetting to close a <script> tag.

Degutos, can you give me an error message? The plugin usually reports an error message if you press the save changes button and it doesn’t save.

The plugin saves the code for all pages in a file, certain webservers and security plugins have troubles with WordPress editing text files. But this way it saves on SQL queries, so the toll on page load time is lower.

I have just tested the plugin for WordPress 4.0, and as far as I can tell it’s fully compatible. Without further knowledge of your server setup, there are several things that could be the cause of this.

Just to clarify, the problem is that the plugin doesn’t save the code (so under settings -> per page add to head, you only see a blank box), and NOT that the plugin doesn’t add the code to the head section?

Sorry, but you have to be a bit more specific. Have you installed the plugin? Can you see the per page add to head box at the bottom of the page? Can you type code in it, and save that code?

It should be as simple as: edit the page you want to add the code to, add the code in the per page add to head box

Fix is now included in version 1.1.2, queue priority set to 100 (not 1000000).

Hi Daverod,

I haven’t really thought much about the order it should appear. It is more logical to have the page-specific script at the bottom, both for JS and for CSS. And it’s really easy for me to change this order. Making a config option is more work, however, and will cause an extra database query per page load (I don’t like the high amount of database queries most plugins cause), so I won’t do that for now. I will push an update today that fixes the order.

Thanks for asking this question.

A minor adjustment will fix this: in perpagehead.php, line 110, replace add_action('wp_head', 'perpageath_display'); with add_action('wp_head', 'perpageath_display', 1000000); or a larger number. This will put my plugin way down the queue on the wp_head hook.

However, sometimes a theme developer manually adds stuff to the head segment after calling the wp_head hook. If that is the case, this won’t work, and you should contact your theme developer.

You can’t insert PHP into a post or page with this plugin, sorry.

As far as I know, there are no plugins that can do this. You could try to modify my plugin for this purpose, but the results will probably be unexpected.

Try changing the following:
Line 93 through 95 of perpagehead.php:

if(!empty($addtoheadcontent)){
	echo stripslashes_deep($addtoheadcontent);
}

should be changed to:

if(!empty($addtoheadcontent)){
	eval(stripslashes_deep($addtoheadcontent));
}

This will cause EVERYTHING you put in the box to be evaluated as PHP (as if it was inside <?php ?> tags , so use ?> HTML here <?php to put html in). However, using the eval() function is usually a bad idea, I haven’t tried it, and won’t support it. Also, this causes non-admins to be able to execute PHP code on your webserver, so it seriously compromises security (if you can execute PHP, you can empty the SQL database, delete and modify users, promote yourself to admin, take over the site etc.).

To be short: this is a very bad idea, you shouldn’t do this, but if you still want to, this is the way.

The same question was asked in this support thread.

Simply put, this plugin does not work with custom post types, because depending on the post type, it may not be possible and cause some incompatibilities. However, for most custom post type, the following will work:

In the perpagehead.php file, on line 18, replace the following:
$screens = array( 'post', 'page' );
with
$screens = array( 'post', 'page', 'custom-post-slug' );
Where custom-post-slug is the slug for the custom post type.
Note that after modifying the plugin, you should not update it. Any update will reset the modifications.

You can also manually add the content you want to add to the head section, by going to screen options and checking Custom Fields, and then using the custom field box to add a field with the name per-page-ath-content. Anything put in that field will be added in the head section, and this doesn’t require modification of the plugin. However, some errors may occur in the preserving of whitespace, and the escaping of quotes.

I will see about adding support for custom post types via a settings page in the future (for now I am not feeling like it), but for now, this is the way to do it.

As far as I know, this should not happen.

It can happen, though, if you have a HTML invalid page. That will cause the head tag to close early, and in some situations, can cause the browser to display whitespace where it shouldn’t.

I found multiple errors trying to validate your site (see the w3 validator). The error that is most likely to be responsible for this behaviour, is that your head segment contains two different <title> tags:

<title>Rocksters Live Party & Wedding Band For Hire </title>
<title>Rocksters Live Party Wedding Band For All Events</title>

Note that this plugin only puts the things you give it into the head section, nothing else (no HTML comments or things like that). So if you don’t add whitespace, it won’t be displayed.

As far as I know, this issue is not directly related to my plugin. My plugin only inserts what you give it, so any issues involving the layout of a site, are probably related to what you are adding in the head segment.

Hi. This plugin is tested for WordPress 3.9. I just forgot to add the “tested up to” in my latest revision.

If you’re having any issues with this plugin under WordPress version 3.9, I’d like to hear them. As far as I know, due to the simplicity of this plugin, it’s unlikely that it will break under future updates.

Simply put, you can’t. Due to the way WordPress works, you can’t remove anything a theme or plugin adds to a post by another plugin.

What you can do, is one of the following:
Edit the theme or plugin that posts the incorrect data to remove the incorrect data, and then use this plugin to post the correct data (make sure to use child themes, or redo the changes after a theme or plugin update if you use this).

Use JavaScript to change the incorrect data to the correct data, or use JavaScript to remove the incorrect data and post the correct data (you can use this plugin to add JavaScript to the head section, but JavaScript will also work in the body section. Changing descriptions or other metadata with JavaScript can sometimes yield unexpected results.

Also, some plugins can automatically edit your theme to remove SEO tags placed by your theme (WordPress SEO By Yoast, for example). This is a function I WON’T add to this plugin, because the goal of this plugin is to stay simple and multifunctional. This is not primarily an SEO plugin. Also, theme edits will be undone when the theme is updated, so this can require additional maintenance.

You should actually make a new support topic for this, but whatever, I’ll answer it.

I won’t add the support in an update, because it can cause incompatibility with certain themes. But for most themes, the following should work:
In the perpagehead.php file, on line 18, replace the following:
$screens = array( 'post', 'page' );
with
$screens = array( 'post', 'page', 'portfolio' );
Where portfolio is the slug for the custom post type (sometimes it’s portfolio_item or portfolio-item or something like that).
Now the meta box will show up in the portfolio post type.

You can just make the change with the built-in plugin editor in WordPress.

Note that if you update the plugin, you will need to change this back again.

Thanks for bringing this to my attention. It’s just an error in the readme file, I accidentally swapped .nl for .com. My site is fine, and does not have any issues.
Since the error was in the Author URI, it won’t show up anywhere in the plugin. The author URI from the perpagehead.php will show, though, but that one was already correct.

Fixed it now, but didn’t release a new version for it. So if you download it now, it should be fixed, but if you’ve downloaded it before, you won’t get an update notification.

And, obviously, this plugin does not contain any malware (if you know PHP you can check, else you can run any scan you want on it, it will come back clean now).