randyhoyt

Is this happening with recurring events? Or with non-recurring events? I see something similar with recurring events, while the non-recurring events are displayed correctly.

You can’t get access to the WordPress functions in that file because you are not running it through the framework. If you hit a URL like this directly …

https://localhost:8888/wordpress/wp-content/themes/simo-portfolio&blog/post-css.php?post-id=1

… it doesn’t run through WordPress at all so it has no access to the functions. Just like if you hit …

https://localhost:8888/wordpress/wp-content/themes/simo-portfolio&blog/single.php

… directly, nothing will happen. It has to run through a WordPress URL.

I’m still not sure why you are not wanting to add the styles to the HEAD of the document. That is a completely valid, standards-based approach. If you have custom CSS that applies to one single page of the site, abstracting that out into a separate file (that isn’t really a file) just does not make any sense: creating a fake re-usable file that won’t ever be re-used is horribly inefficient. (One extra unnecessary server request, too.) Especially if you have to query the database to figure out if it has custom values in the header.php and then have to query the database again in the post-css.php to output it.

Here’s the tutorial that walks through how to do it this way …

https://www.wprecipes.com/how-to-embed-css-in-your-posts-with-a-custom-field

… though I would recommend adding it to functions.php and wp_head() instead of directly in header.php.

Here’s some code for the field that goes in the template definition section:

[Related_Post_ID]
type = select
code = 0
hideKey = true
label = Related Post

The attribute code = 0 references the PHP code section further down the page. The following code should go in the PHP Code section, in the Code #0 box.

global $wpdb;
$items = $wpdb->get_results("SELECT ID, post_title
FROM $wpdb->posts
where post_type = 'post'
and post_status = 'publish'
order by post_date DESC");
$i = 0;
foreach ($items as $item) {
	$values[$i] = $item->ID;
	$valueLabel[$i] = $item->post_title;
	$i++;
}

If all goes well, this will give you a dropdown list of all your posts.

The first box for each line number listed the original code, while the second box for each line number listed the change.

However, I don’t think these changes are necessary any more. The latest version of the plugin addresses this. What version are you running?

Do you want this field to be a select list from which you can pick on related post?

Thank you for addressing these issues so quickly. The templates for posts now only appear on posts, and the templates for pages only appear on pages. Thank you!

Just four datasets and that’s all.

This is probably something that I provide. Send me an email through my web site’s contact form [https://randyhoyt.com/contact], and I’d be happy to send you an example custom template that I’m using. (I hope to put together a video tutorial soon about how to do this — but there’s just only so much time in one day. :~)

@nomatteus

I cannot thank you enough for providing this fix. I was too far into a project with CYC to switch to something different, though I expect I will be trying Theme My Login for future projects.

Thanks again!
~randy

I am using the following code to determine which template is used for a given post.

$options = get_option('custom_field_template_data');
$custom_field_template = $options['posts'][$post->ID];

That code should put the ID of the template into that variable.

The popup bubbles are not working for me in Internet Explorer: I have tried it with version 1.2.12 and with version 1.6.0. Clicking on the bubble in Internet Explorer produces a JavaScript error:

Line: 238
Char: 12
Error: ‘console’ is undefined
Code: 0

I have created a blank installation to demonstrate the error. I installed WordPress 2.7.1, ICS Calendar 1.6.0, added my calendar’s ICS file to the Settings, and then added the shortcut to the default About page. There are no other plugins or anything else installed. You can see the error here:

https://dev.amesburyweb.com/ics-calendar-test/?page_id=2

I found a bit of a hack-y way to do this. I added the following code to the functions.php file in my active theme:

function hide_wordpress_tinymce_classes() {
    echo '<style type="text/css">';
    echo '    tr#mce_1 {display: none !important;}';
    echo '    tr#mce_2 {display: none !important;}';
    echo '    tr#mce_3 {display: none !important;}';
    echo '    tr#mce_4 {display: none !important;}';
    echo '    tr#mce_5 {display: none !important;}';
    echo '    tr#mce_6 {display: none !important;}';
    echo '</style>';
}
add_action('admin_head', 'hide_wordpress_tinymce_classes');

It appears that in WordPress 2.7.1 there are six of these default classes. Each item in the dropdown as an ID specified in the HTML, so I just added CSS to the top of the page that makes the first six options invisible.

I’m pretty sure this cannot be changed. The page_on_front and page_for_posts are using the same title.

In version 3.2, you can simply delete all the code in [openid/comments.php] to make this work. Contributors can still use Open ID to access the backend, but Open ID is not utilized for visitors leaving comments. (I’m not sure when this approach started working, but I think that before 3.x there was not an [openid/comments.php] file.)

ProjectManager 2.2 takes care of this. Thanks!