Digging into WordPress » CSS

Displaying Theme Data with WordPress

Jeff Starr — Wed, 14 Dec 2011 18:36:29 +0000

A cool trick you can do with WordPress is display information directly from your theme’s style.css stylesheet. I recently used this on a site where the theme’s version number is used throughout the template to keep things current and consistent.

get_theme_data()

The function that makes it possible is called get_theme_data(), and it simply returns an array of information about any of your theme files. Here is how it’s used in your theme template:

So $theme_filename is required and should be the path and filename of your theme’s style.css file. There is no default value for this, so you need to ensure a proper value.

So what information can you display with get_theme_data()? The function returns an array of values that basically comprises the different meta items in your stylesheet. Here is a list of possible return values (all strings):

Name – theme name
Title – either theme name or linked theme name
URI – theme URI
Description – wptexturized version of the theme name
AuthorURI – theme author URI
Template – theme parent template, if exists
Version – theme version number
Status – theme status (default: publish)
Tags – theme tags
Author – author name or linked author name

Note that these return values are case-sensitive and will not work if the first letter is not capitalized.

Examples

The Codex provides this example for getting and displaying the theme Name and Author:

This should get you going.. just copy/paste into your theme template and indicate the theme name in that first line of code. Displaying other bits of theme data is matter of editing/replicating those last two lines.

Once you see how it works, you can do cool stuff with it, like display your theme’s version number sort of globally throughout your site. I’m using this technique to append version parameters to my stylesheet URLs, like so:

..and the output markup looks like this (notice the appended version parameter, ?v=1.3):

Because I am using multiple stylesheets, this method really saves a LOT of time trying to keep track of everything. Here is the theme_version() function that goes in your theme’s functions.php file:

// display version number
function theme_version() {
    $theme_name = 'xycss'; // customize with your theme name
    $theme_data = get_theme_data( get_theme_root() . '/' . $theme_name . '/style.css' );
    echo '?v=' . $theme_data['Version'];
}

And with a few modifications, you can also display your theme’s information in your posts and pages via shortcode:

// version number shortcode
function theme_version_shortcode() {
    $theme_name = 'xycss'; // customize with your theme name
    $theme_data = get_theme_data( get_theme_root() . '/' . $theme_name . '/style.css' );
    return $theme_data['Version'];
}
add_shortcode('theme_version', 'theme_version_shortcode');

With that second snippet in your functions.php file, displaying your theme info directly in pages is as easy as writing this:

[theme_version]

..and the output:

1.3

It’s pretty cool stuff, and I’m sure there’s tons more you can do with it too. If you know any tricks or tips, please share in the comments, Thanks :)

Make the Visual Editor Actually WYSIWYG

Chris Coyier — Sun, 28 Nov 2010 16:18:14 +0000

In otherwords, match what you see when creating/editing a Post or Page in the WordPress visual editor to what you get when you actually publish it. It’s easier than you might think! Basically you can declare a special CSS file that the visual editor will use to render itself while you are editing it. If the styles in that CSS file match the styles in your live theme’s CSS file, you are straight up WYSIWYG (What You See Is What You Get).

1) Declare CSS for Visual Editor

Very easy, one-liner in your functions.php file.

// Add CSS to Visual Editor
add_editor_style('css/custom-editor-style.css');

The file path that you pass as a parameter is relative to your theme’s root. Make sure to actually create this file in your theme folder, at the specified location!

2) Make Sure You Have a Common Class To Work With

The HTML markup for the posts on your site are very likely wrapped within a container element. Perhaps something like:

Then your typography CSS likely uses that class name to to create typography specific to posts:

.post h1, .post h2, .post h3, .post h4 { font-family: MuseoLight, Georgia, serif; font-weight: normal; margin: 0 0 10px 0; }
.post h2 { font-size: 28px; }
.post h2 { padding: 10px 180px 10px 15px; background: #237abf url(../images/title-bg.png) repeat-x; margin: 0; line-height: 1.3; font-size: 22px; }
.post h2, .post h2 a { color: white; text-shadow: 0 1px 2px #143855; }
.post h2 a:hover { color: #b8e0ff; }
.post h3 { font-size: 20px; padding: 5px 0; margin: 30px 0 15px 0; border-top: 1px solid #ccc; border-bottom: 1px solid #ccc; }
.post h4 { font-size: 18px; }
.post p { margin: 0 0 10px 0; }
.post pre { background: #eee; padding: 15px; overflow: auto; margin: 0 0 15px 0; border: 1px solid #ddd; }
.post pre code { font-size: 11px; }
.post code { background: #eee; font: 12px Monaco, Courier, Monospace; color: #0E304A; }
.post h3 code { font-size: 18px; }
.post acronym, abbr { border-bottom: 1px dotted #514031; cursor: help; }
.post ins { text-decoration: underline; }
.post del { text-decoration: line-through; }
.post a { outline: none; text-decoration: none; color: #19517C; background: #eee; border: 1px solid #ddd; padding: 1px 3px 2px 3px; -webkit-border-radius: 3px; -khtml-border-radius: 3px; -moz-border-radius: 3px; border-radius: 3px; }
.post a:hover { color: #fff; background: #143855; border: 1px solid #143855; }

It would be nice if we could just copy and paste that over to the CSS file we declared in Step 1. The problem is, the Visual Editor doesn’t have that same class name inside of it. So if we did a straight up copy-and-paste, none of these styles would apply. Rather than re-jigger all our CSS to not use that class name, we can actually just force the visual editor to also have that class name.

Just put this in functions.php:

// Add body class to Visual Editor to match class used live
function mytheme_mce_settings( $initArray ){
 $initArray['body_class'] = 'post';
 return $initArray;
}
add_filter( 'tiny_mce_before_init', 'mytheme_mce_settings' );

This isn’t quite as efficient as referencing a single file, but at least you can copy and paste easily. If you are the type of person who separates CSS out into different files (like Typography has it’s own typography.css), then you are more than welcome to reference the same CSS both for Visual Editor and in the live theme. That’s just now how I roll.

The body class trick is from Seamus Leahy. Thanks Seamus!

The Result:

Check out this example of this very post from back end to front end:

You can literally do anything CSS can do, right down to the custom web fonts!

WordPress Default CSS Styles

Jeff Starr — Mon, 24 May 2010 08:52:22 +0000

WordPress gives us full control over the presentation of our websites. We specify which classes and attributes to use in our template files, and then apply CSS using our theme’s custom stylesheet. Behind the scenes, WordPress generates its own classes and IDs, and applies them to specific HTML elements in theme files and database content. Having these default hooks available makes it super-easy to custom-style your theme’s blockquotes, post images, widget items, and much more.

In addition to generating default classes for your site’s “front-end” (public-facing) pages, WordPress also employs a default set of CSS attributes for the Admin, or “back-end” pages. If you’ve ever delved into the convoluted CSS stylings of the WordPress Admin, you will understand why we focus exclusively on front-end attributes in this article. The goal is to include all classes and IDs generated for database content, theme template files, and default widget items.

Fortunately, most (if not all) of your WP CSS work happens at the “theme” or “post” level. And when you do need to style the Admin, it’s usually easiest to just do it en bloc via plugin. You can also do it the old-fashioned way.

Different Types of Default WordPress Styles

In this DiW post, we assemble and dissect as many of the default front-end WordPress CSS attributes that we could find. It turns out there are many more automatically generated classes and IDs than you probably realize, including those for more commonly styled elements such as the following:

Images included via WordPress’ WYSIWYG Post Editor
Image captions and galleries included via the WYSIWYG Post Editor
The body_class() and post_class() template tags
WordPress’ automatic “smilies”
WordPress’ default widgets

Some of these features are used quite frequently, while others not so much. It’s a good idea to cover your bases for these items, especially when producing publicly available themes. By including some basic styles for key CSS attributes, you ensure a more complete and rewarding experience for your theme’s users (and their users as well).

Fortunately, not all of WordPress’ default CSS attributes require explicit styling. Many default classes and IDs are generated and included as a matter of convenience. Conversely, there some core styles that are essential for public themes. So to organize things, we have two somewhat arbitrary types of default attributes, “essential” or “optional” – and here they are now:

Essential WordPress Styles

These are default WordPress attributes that should be styled with CSS:

Default styles applied by WordPress’ WYSIWYG editor
Default styles generated by WordPress’ default widgets
Comment styles – threaded comments, specific comment styles, et al.
Miscellaneous WordPress styles

Optional WordPress Styles

These are default WordPress attributes that should be styled only when needed:

WordPress Page Listings
CSS attributes generated by body_class()
CSS attributes generated by post_class()
Miscellaneous WordPress styles

For each of these sections, we’ll review the associated functionality and then present the default CSS styles generated and output by WordPress. It is ultimately up to you to decide the best approach for dealing with these default styles. If nothing else, it is wise to provide styles for WordPress’ WYSIWYG Editor items and perhaps widgets, if enabled. This is functionality that users typically employ while working with their site.

For all of these CSS attributes, we are merely presenting the selectors devoid of any preset styles. Only the styles for the WYSIWYG Editor are included, mostly because they are styled according to the WordPress Codex. Everything else is entirely up to you.

[ ^ ] WordPress CSS – WYSIWYG Editor Styles

When you are working with WordPress’ WYSIWYG Editor in the Edit Post screen, WordPress applies context-specific CSS attributes to certain elements when they are included in your post. For example, when inserting images, you can specify whether the images are floated left, right, or even centered. To do this, WordPress applies classes such as alignleft, alignright, or aligncenter. Without defining styles for WordPress’ default hooks, images and other elements may not display as intended.

Thus, at a bare minimum, if you are building a theme that will be used by the general public, it is wise to include the following basic styles for the items attributed via the WYSIWYG Editor:

/* == WordPress WYSIWYG Editor Styles == */

.entry-content img {
	margin: 0 0 1.5em 0;
	}
.alignleft, img.alignleft {
	margin-right: 1.5em;
	display: inline;
	float: left;
	}
.alignright, img.alignright {
	margin-left: 1.5em;
	display: inline;
	float: right;
	}
.aligncenter, img.aligncenter {
	margin-right: auto;
	margin-left: auto;
	display: block;
	clear: both;
	}
.alignnone, img.alignnone {
	/* not sure about this one */
	}
.wp-caption {
	margin-bottom: 1.5em;
	text-align: center;
	padding-top: 5px;
	}
.wp-caption img {
	border: 0 none;
	padding: 0;
	margin: 0;
	}
.wp-caption p.wp-caption-text {
	line-height: 1.5;
	font-size: 10px;
	margin: 0;
	}
.wp-smiley {
	margin: 0 !important;
	max-height: 1em;
	}
blockquote.left {
	margin-right: 20px;
	text-align: right;
	margin-left: 0;
	width: 33%;
	float: left;
	}
blockquote.right {
	margin-left: 20px;
	text-align: left;
	margin-right: 0;
	width: 33%;
	float: right;
	}
.gallery dl {}
.gallery dt {}
.gallery dd {}
.gallery dl a {}
.gallery dl img {}
.gallery-caption {}

.size-full {}
.size-large {}
.size-medium {}
.size-thumbnail {}

Lots of good stuff there, but no predefined styles for some of the Gallery items, such as .gallery dl and .size-thumbnail, as seen near the end of the list. Also, if you are using reset styles for margins and padding, you can strip out quite a few rules from this default set.

Quick Tip: an easy way to ensure that everything is looking great is to simply create a test post in which you include each of the WYSIWYG items. Then include this set of default styles and fine-tune as desired.

As with most everything else WordPress-related, for more information on these default WordPress styles, check out the Codex. The default selectors above basically define CSS styles for images, captions, galleries, blockquotes, and smilies &ndash: in other words, all of the items that you can include using WordPress’ built-in WYSIWYG Editor.

[ ^ ] WordPress CSS – Miscellaneous Styles

After styling the essentials, you may also want to keep an eye out for these miscellaneous WordPress classes:

/* == WordPress CSS - Miscellaneous Styles == */

/* category links */
 li.categories {}  
 li.cat-item {}
 li.cat-item-{id} {}
 li.current-cat {}
 li.current-cat-parent {}
 ul.children {}

/* blogroll links */
.linkcat {}
.blogroll {}

/* read-more links */
.more-link {}

Not all of them are going to be used in every theme, but they are used quite commonly, especially the .read-more class, which is frequently used for archive, category and tag pages. It may be wise to anticipate their presence to ensure that nothing is going to break your theme’s design. Also, for more information on the category-links template tag, visit the WP Codex: wp_list_categories.

[ ^ ] WP CSS – Page Listings

If you are using WordPress’ built-in page-listing functionality provided by the wp_list_pages() and wp_page_menu() template tags, there are a variety of items that should be styled. These may look like a lot of work, but once you get the pattern down, it goes pretty quickly. Hopefully the following list will prove a useful reference during your next page-list styling session:

/* == WP CSS - Page Listings == */

.pagenav {}               /* outermost list item */
.page_item {}             /* any page item */
.page-item-{id} {}        /* specific page id */
.current_page_item {}     /* current page */
.current_page_parent {}   /* parent of current page */
.current_page_ancestor {} /* any ancestor of current page */

.pagenav ul,
.pagenav .current_page_item ul,
.pagenav .current_page_ancestor ul,
.pagenav .current_page_ancestor .current_page_item ul,
.pagenav .current_page_ancestor .current_page_ancestor ul,
.pagenav .current_page_ancestor .current_page_ancestor .current_page_item ul,
.pagenav .current_page_ancestor .current_page_ancestor .current_page_ancestor ul {}

.pagenav  ul ul,
.pagenav .current_page_item ul ul,
.pagenav .current_page_ancestor ul ul,
.pagenav .current_page_ancestor .current_page_item ul ul,
.pagenav .current_page_ancestor .current_page_ancestor ul ul {}
.pagenav .current_page_ancestor .current_page_ancestor .current_page_item ul ul, 
.pagenav .current_page_ancestor .current_page_ancestor .current_page_ancestor ul ul {}

Again, the easiest way to understand this spaghetti is to create a list by including wp_list_pages() in a theme template file, and define a big red border (or whatever) for each declaration block. Check the results and you should quickly recognize the pattern. For more information on the template tags used to generate these rules, go to Codex:

You may also want to check out some delicious recipes for WordPress page navigation, which provide everything you need to create the perfect page navigation menus for your website.

[ ^ ] WordPress CSS – Default WordPress Widgets

There are literally thousands of widgets available to WordPress users, but there is a handful of very common widgets that are frequently used with widgetized themes. If you are planning on widgetizing your theme, you should include some styles for some of the more popular widgets. Many of the widgets included with the retiring Kubrick theme have become very common, if not expected:

As the theme designer, you will decide which (if any) widgets to include in your theme, so you will know exactly which styles to apply. Here are the generic rules for some of the more common WordPress widgets:

/* == WordPress CSS - Default WordPress Widgets == */

.widget {}

/* links widget */
.widget_links {}
.widget_links ul {}
.widget_links ul li {}
.widget_links ul li a {}

/* meta widget */
.widget_meta {}
.widget_meta ul {}
.widget_meta ul li {}
.widget_meta ul li a {}

/* pages widget */
.widget_pages {}
.widget_pages ul {}
.widget_pages ul li {}
.widget_pages ul li a {}

/* recent-posts widget */
.widget_recent_entries {}
.widget_recent_entries ul {}
.widget_recent_entries ul li {}
.widget_recent_entries ul li a {}

/* archives widget */
.widget_archive {}
.widget_archive ul {}
.widget_archive ul li {} 
.widget_archive ul li a {}
.widget_archive select {}
.widget_archive option {}

/* tag-cloud widget */
.widget_links {}
.widget_links li:after {}
.widget_links li:before {}
.widget_tag_cloud {}
.widget_tag_cloud a {}
.widget_tag_cloud a:after {}
.widget_tag_cloud a:before {}

/* calendar widget */
.widget_calendar {}
#calendar_wrap {}
#calendar_wrap th {}
#calendar_wrap td {}
#wp-calendar tr td {}
#wp-calendar caption {}
#wp-calendar a {}
#wp-calendar #today {}
#wp-calendar #prev {}
#wp-calendar #next {}
#wp-calendar #next a {}
#wp-calendar #prev a {}

/* category widget */
.widget_categories {}
.widget_categories ul {}
.widget_categories ul li {} 
.widget_categories ul ul.children {}
.widget_categories a {}
.widget_categories select{}
.widget_categories select#cat {}
.widget_categories select.postform {}
.widget_categories option {}
.widget_categories .level-0 {}
.widget_categories .level-1 {}
.widget_categories .level-2 {}
.widget_categories .level-3 {}

/* recent-comments widget */
.recentcomments {}
#recentcomments {}
#recentcomments li {}
#recentcomments li a {}
.widget_recent_comments {}

/* search widget */
#searchform {}
.widget_search {}
.screen-reader-text {}

/* text widget */
.textwidget {}
.widget_text {}
.textwidget p {}

That’s obviously a lot of work for any designer, but there are many similar elements that would probably look best with matching styles. For example, instead of multiple declarations for list elements such as .widget_archive ul li, .widget_pages ul li, and .widget_recent_entries ul li, we can simplify by combining them into a single declaration, for example:

.widget_pages ul li,
.widget_archive ul li,
.widget_recent_entries ul li {}

In other words, when it comes to styling widgets, there’s a lot of repetition that may be consolidated and streamlined in your stylesheet. As you apply styles for WordPress’ default widgets, keep an eye out for exploitable selector patterns and similar styles that may be combined to save time and effort.

[ ^ ] WordPress CSS – Comment Styles

Styling comments is the bane of WordPress theme designers, especially when threaded/nested comments are enabled. The deeper they go, the more time you’re going to spend with them, but thankfully WordPress makes things a little easier by providing plenty of precise CSS hooks. Of course, if threaded comments are disabled, there is no need to bother with most of these classes. But when they are used, many of the following selectors should define style:

/* == WP CSS - Comment Styles == */

.commentlist .reply {}
.commentlist .reply a {}

.commentlist .alt {}
.commentlist .odd {}
.commentlist .even {}
.commentlist .thread-alt {}
.commentlist .thread-odd {}
.commentlist .thread-even {}
.commentlist li ul.children .alt {}
.commentlist li ul.children .odd {}
.commentlist li ul.children .even {}

.commentlist .vcard {}
.commentlist .vcard cite.fn {}
.commentlist .vcard span.says {}
.commentlist .vcard img.photo {}
.commentlist .vcard img.avatar {}
.commentlist .vcard cite.fn a.url {}

.commentlist .comment-meta {} 
.commentlist .comment-meta a {}
.commentlist .commentmetadata {}
.commentlist .commentmetadata a {}

.commentlist .parent {}
.commentlist .comment {}
.commentlist .children {}
.commentlist .pingback {}
.commentlist .bypostauthor {}
.commentlist .comment-author {}
.commentlist .comment-author-admin {}

.commentlist {}
.commentlist li {}
.commentlist li p {}
.commentlist li ul {}
.commentlist li ul.children li {}
.commentlist li ul.children li.alt {}
.commentlist li ul.children li.byuser {}
.commentlist li ul.children li.comment {}
.commentlist li ul.children li.depth-{id} {}
.commentlist li ul.children li.bypostauthor {}
.commentlist li ul.children li.comment-author-admin {}

#cancel-comment-reply {}
#cancel-comment-reply a {}

These are all of the classes and IDs that I could find, and they all seem to be pretty self-explanatory, especially after using them a few times. Even so, consider the collection a work in progress. As new information is discovered, the list will continue to improve (hypothetically speaking). Many of these selectors target markup elements generated via WordPress’ built-in wp_list_comments() template tag. Even when using a custom callback function for your comments loop, many of these CSS classes will be available for your styling convenience.

[ ^ ] WordPress CSS – body_class()

As of version 2.5, WordPress provides the body_class() template tag, which is included in the element of your theme’s markup. When included, this tag outputs a variety of context-dependent class names that facilitate styling different types of page views. We talk more about body_class() here and here, but for now, let’s look at the different classes WordPress generates for this powerful tag:

/* == WP CSS - body_class() == */

.rtl {}
.home {}
.blog {}
.archive {}
.date {}
.search {}
.paged {}
.attachment {}
.error404 {}
.single postid-(id) {}
.attachmentid-(id) {}
.attachment-(mime-type) {}
.author {}
.author-(user_nicename) {}
.category {}
.category-(slug) {}
.tag {}
.tag-(slug) {}
.page-parent {}
.page-child parent-pageid-(id) {}
.page-template page-template-(template file name) {}
.search-results {}
.search-no-results {}
.logged-in {}
.paged-(page number) {}
.single-paged-(page number) {}
.page-paged-(page number) {}
.category-paged-(page number) {}
.tag-paged-(page number) {}
.date-paged-(page number) {}
.author-paged-(page number) {}
.search-paged-(page number) {}

As you can see, these classes enable us to easily target elements on any specific type of page. For example, if you want to customize the presentation of your search results, you could define your styles using the .search-results class. This flexibility offers greater control over the granular construction of your WordPress theme. For more information on the body_class() tag, check out the WordPress Codex.

[ ^ ] WordPress CSS – post_class()

As with body_class(), the post_class() template tag outputs a variety of context-dependent class names for your posts. The post_class() tag makes it easy to target and style specific posts and post-types, as well as posts from specific categories or tags. Here are the different class names automatically generated by post_class():

/* == WP CSS - post_class() == */

.post-id {}
.post {}
.page {}
.attachment {}
.sticky {}
.hentry {}
.category-misc {}
.category-example {}
.tag-news {}
.tag-wordpress {}
.tag-markup {}

Again, these classes seem pretty self-explanatory, but if anyone happens to know the definition of the .hentry class, it would be nice to know – I couldn’t find anything, and sadly didn’t take time to test. Basically, these classes enable you to define styles for specific types of posts, attachments, stickies, categories and tags. You can also include your own classes to post_class(), and even include current category IDs. For more information on the post_class() tag, check out the WordPress Codex.

Call for updates

So what’s missing? Notice any errors? I did my best to research everything and organize everything as accurately as possible, but this turned out to be a bit more insane than I had planned, and so there is definitely room for improvement. If you see anything that is inaccurate or incomplete, please advise in the comments. It would be great to fine-tune a complete reference for all of WordPress’ default CSS styles and hooks all in one place.

Specify Unique CSS File Per Post

Chris Coyier — Mon, 10 May 2010 21:20:39 +0000

I’m a HUGE fan of being able to link up a CSS file on a per-page basis. I just find it extremely common that a page needs CSS styling unique to it, and I hate litering a sites main stylesheet with customizations that only one particular page needs. We’ve talked about this before, and even created a custom method for doing so, as well as mentioned the art direction plugin, which makes this easily possible.

Both of those methods are still sweet, but I find in general that I like to write my CSS in actual CSS files I keep in my theme and can edit using whatever CSS editor I like, as well as keep things clean and simple in the admin. So, I’ve altered the technique a bit.

The idea is to add a simple text input to the page editor, right underneath the content area, where you can manually specify the name of a CSS file. In the image below, you can see I’ve also added one for JavaScript.

To add this to your site, it’s just some code to add to the functions.php file. Should work for any site.

// Custom Stylesheet box in Pages/Posts
add_action('admin_menu', 'digwp_custom_css_hooks');
add_action('save_post', 'digwp_save_custom_css');
add_action('wp_head','digwp_insert_custom_css');
function digwp_custom_css_hooks() {
	add_meta_box('custom_css', 'Name of custom CSS file', 'digwp_custom_css_input', 'post', 'normal', 'high');
	add_meta_box('custom_css', 'Name of custom CSS file', 'digwp_custom_css_input', 'page', 'normal', 'high');
}
function digwp_custom_css_input() {
	global $post;
	echo '';
	echo '';
}
function digwp_save_custom_css($post_id) {
	if (!wp_verify_nonce($_POST['custom_css_noncename'], 'custom-css')) return $post_id;
	if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return $post_id;
	$custom_css = $_POST['custom_css'];
	update_post_meta($post_id, '_custom_css', $custom_css);
}
function digwp_insert_custom_css() {
	if (is_page() || is_single()) {
		if (have_posts()) : while (have_posts()) : the_post();
		  $filename = get_post_meta(get_the_ID(), '_custom_css', true);
		  if ($filename) {
			echo "";
          }
		endwhile; endif;
		rewind_posts();
	}
}

If you are happy with just CSS only, you can stop there. If you would like the JavaScript box as well, here is that code.

// Custom JavaScript in Pages/Posts  (...lots of repeated code, could be better)
add_action('admin_menu', 'digwp_custom_js_hooks');
add_action('save_post', 'digwp_save_custom_js');
add_action('wp_head','digwp_insert_custom_js');
function digwp_custom_js_hooks() {
	add_meta_box('custom_js', 'Name of custom JavaScript file', 'digwp_custom_js_input', 'post', 'normal', 'high');
	add_meta_box('custom_js', 'Name of custom JavaScript file', 'digwp_custom_js_input', 'page', 'normal', 'high');
}
function digwp_custom_js_input() {
	global $post;
	echo '';
	echo '';
}
function digwp_save_custom_js($post_id) {
	if (!wp_verify_nonce($_POST['custom_js_noncename'], 'custom-js')) return $post_id;
	if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return $post_id;
	$custom_js = $_POST['custom_js'];
	update_post_meta($post_id, '_custom_js', $custom_js);
}
function digwp_insert_custom_js() {
	if (is_page() || is_single()) {
		if (have_posts()) : while (have_posts()) : the_post();
		    $filename = get_post_meta(get_the_ID(), '_custom_js', true);
		    if ($filename) {
			 echo "";
            }
		endwhile; endif;
		rewind_posts();
	}
}

You could probably combine these together a bit better than I have done here, it’s a bit redundant.

How it Works

There are three things going on here, which tap into three existing WordPress “hooks”.

Adds text inputs to the page editing screen of the admin using the admin_menu hook and the add_meta_box function
Save the values of those text inputs when the page is saved using the save_post hook
Output or