1. Setup Storylines, the Comic Category will of course be the root.  The storylines you will use will be the comics names.  So create children off the root comic category as the individual comics.
2. Disable the comic off the front page.
3. Add latest thumbnail widgets and set those widgets to the appropriate category.  (yes you can do this now) So that the thumbnail for the latest comic thumbnail is for that individual comic.
4. Drag the Comic Navigation widget into under-comic.   Disable *all* the checkmarks except first in category, next in category previous in category and last in category.  Those particular navigation buttons will let you navigate PER category, the first will go to the first comic in the category, next IN category, and LAST comic in the category, etc..
5. Post the comic into the appropriate storyline category, remember 1 category per comic post, that being the comic you want to post it in.

And that's it.   There's still the 1 comic post per day, but you knew that.     If you look on http://frumph.net you will see that I have a Rascal Comic and a Pinups comic both with their own navigation.

If you plan on wanting each comic to have their own site, realistically you should, then WordPress 3.0's Multi-Site feature is what you are really looking for and it's very easy to setup.

Have fun!

- Phil

(updated 07/26/2010)

Changes:

1. directory/images location fixes for subdirectory installations
2. fixed the storylines archive dropdown category box to display proper storyline category order (thanks dante8)
3. fixed bug with sidebar bleeding with $title by changing it to $sidebartitle
4. all of the widgets have been renamed to remove the 'comicpress' title in front of them so that they're found alphabetical on the list, which also means you will lose your widgets, just re-add them to the sidebars, removed excess code in every one of them cleaning them up
5. first_in_category, previous_in_category, next_in_category, last_in_category buttons now exist so you can have multiple comics on each site, including the latest thumbnail widget to specify which category you want to display.  setup storylines, make a storyline category for each comic then checkmark those buttons on the navigation put it undercomic and it will *only* navigate that single category storyline.
6. fixed comic blog post widget to display content again
7. added  the wp 3.0 background option in the appearance menu *shrug could use CSS with companion* but some people want it easy on them
8. numerous other little changes to fix issues with 2.9.1.2
9. checkchildthemeforfile function no longer exists
10. childfunctions.php in the child themes is now child-functions.php

INSTALLING

1. You WILL have to redo your widgets (not text widgets, your regular comicpress widgets.
2. Your child themes will all still work, however again; check your custom functions for function name changes., replace with originals and remodify them.
3. childfunctions.php in the child themes is now child-functions.php
4. Remove any other versions of comicpress that have ComicPress as a name in the style.css.
5. DELETE old, replace with new.  Do *not* just FTP over older versions.

REQUIREMENTS

1. WordPress 3.0
2. PHP 5
3. The knowledge that this is just a theme that works with WordPress, the theme is designed with CSS, you should have a small amount of knowledge in designing your look of your site utilizing CSS.

DISCLAIMER

1. ComicPress Dev's are not responsible for hosting that has permission issues, if you have problems with permissions you can ask however we can at anytime refuse assistance with problems based on permissions for PHP to access your hosting because of those permissions.   The proper customer service to ask is your hosting provider's  customer service.
2. ComicPress is a blank-slate theme, which means developing the look of your site is your responsibility.   ComicPress developers have provided the theme companion plugin, the ability to make child themes and an extremely large amount of CSS classes and ID's to work with.  CSS and the knowledge of how CSS works is something that is utilized on the web to design every website.

As a bonus to all workshop attendee's, I will be providing information on how to receive the automated Cast addon to ComicPress child themes as a free download.   The casts addon allows you to display your cast members in a totally new to ComicPress way, showing when they first appeared in the comic, how often they have been in the comic, all of the comics they were in with links and other statistics as well as individual biographical information!  (I might even have time to include the relationship tree with that too )

If you cannot attend the workshop I will be providing this child theme addon for ComicPress for around $29 (after) the con is over.   The addon will be offered as a one time purchase with unlimited upgrades or free for attending any workshops.

- Phil

1. The comics directories need to be located in the wp-content/uploads directory now.  This is because it was a request to lock down wordpress sites and only have the uploads directory available as such on some systems that don't have proper permission setups.   This also made it easier to code and reduced processing by like 10% just from that change alone. (this is for non-multisite, multisite uses the directories based on the multisite info)
2. ComicPress Manager is no longer needed, you can ditch it with CP 3.0 - Everything's in the theme.
3. The multisite (wpmu) mu-plugin is no longer needed.
4. CP 3.0 is completely plug & play.  You activate the theme, you add a new comic, no configuring.  Although you can adjust the configuring after installing, it's not necessary to get up and going to configure anything.
5. There is no comicpress-config.php anymore.  No need to worry about losing your options/config on updates.
6. Comics are "attached' to the post.   And there are several advanced options available including comics in different languages available.
7. There are no more 'category' separation from comic and blog as you know it now.   The comic's are in their own post type.  Completely separate from the regular blog posts so not only will there never be a conflict again they really just are not seen the same way again.
8. Backwards compatibility:  Although we are leaving the ability to have backwards compatibility where the posts in the comic post type will look at the comics directory via filename date if there isn't a comic attached to it, it will search your comics folder for a file with the old date method on it; we don't want people to keep utilizing this method in the future, need to train comic users to just upload their comic with whatever filename they want with the upload controls.
9. There is an upgrade script that will convert all your current comics from the old post style to the new post type.  Just select your primary comics directory (in the script) and go.  Although it will remove all your categories and tags since those are no longer used and are replaced with Chapters and other comic related functions.
10. All ComicPress versions of the theme will remain free.
11. ^ However, your wondering where are those cool NEW features we were adding went?  Lemme tell ya, instead of including them in the theme we'll be having Child Themes available with those features in them.  Yes, for pay.  Don't even bother griping about it, that one is a done deal.   The theme itself will always remain free and if you want to buy a child theme with extra features you can.  Those child themes will be available from their individual developer separately from ComicPress.  If you are interested in creating child themes for sale we'll have an area on the website to link to the various child themes people develop.
12. Soon as the initial release is done while in beta mode we'll have a continual stream of child themes available with so many different options for the site look it's going to be silly.   I have quite a few of them already done and waiting to be put up.
13. Your current child themes will be compatible up to a point.  The CSS and images are Absolutely Compatible, things like the custom child functions, widgets and code will need to be updated.
14. This is *(not)* the ComicPress Premium package we were making previously.   Almost though.  We stripped out pretty much all the new stuff and are making 3.0 the new post type with the new system.  What we DID leave in is the memory management, core options and new comic method.
15. We're waiting on Tyler's decision to decide to make this as a normal ComicPress upgrade or call it a new ComicPress name. (note: he decided that this IS going to be ComicPress 3.0 and not an offshoot, he loved it that much)
16. Stop editing the original theme already and learn how to do a child theme: http://frumph.net/wordpress/comicpress/convert-your-comicpress-2-9-site-to-use-a-child-theme/

More information on what a child theme is here:
http://frumph.net/wordpress/comicpress-2-9-parent-child-theme-relationship/

Original Post is here:
http://frumph.net/wordpress/faq/creating-a-custom-child-theme-for-comicpress-2-9/

A child theme will contain your graphic sets for navigation, avatars, calendars, moods and site graphics;  Your custom CSS, widgets and code overrides.

I have provided a blank comicpress child theme here:
http://frumph.net/downloads/comicpress-blank.zip

1. Modify the directory name to one of your chosing, i.e. /comicpress-mysitename/
2. Change the 'Theme Name, Author and Author URI' inside the child theme's style.css to your custom names.
3. Put your custom sets of navigation, avatars, calanders, moods in the images folder in this Child Theme, uses the same base structure as the main ComicPress theme, (if you have them, otherwise you can make them later).
4. If you are using a custom-menubar.php, that too goes into this child theme.
5. The widgets directory in the child theme is where you can place custom widgets if you make any.
6. Design your site with Companion or putting the CSS into this child theme's style.css
7. Take a screen capture of your designed site and replace the screenshot.png file in this child theme.

1. Modify the directory name.

The comicpress-blank.zip file has a directory inside of it called comicpress-blank, you can either upload it via the dashboard -> themes -> add new [upload], or you can ftp the contents into the wp-content/themes directory of your wordpress installation.

When it is on your server, rename the directory to something more coherent then 'blank' so that you can recognize it as your own.

The end result will be something like this  /wp-content/themes/comicpress-yoursitename/  and the style.css for the child theme is in the /wp-content/themes/comicpress-yoursitename/style.css

2. Change relevant information inside the style.css of your child theme.

/*
Theme Name: ComicPress Blank
Theme URI: http://comicpress.org
Template: comicpress
Description: Publish a comic with WordPress.  <a href="http://comicpress.org">Visit the ComicPress Website.</a>
Author: Your Name Here
Author URI: http://Your personal site url here/
Version: 1.0
*/

This is how the blank child theme originally looks. You will want to modify this to have the information you want in your child theme. Change the theme name to represent your webcomic or site. You're the author, change that as well and your website too.

4. Put your custom stuff in the child theme.

Now that you have your own child theme you can centralize the location of all of your images & stuff that is used on your site. The child themes images directory is where you place your site design images that are relevant to the style.css inside the child theme directory. When using the child themes style.css and your images are in the child themes images directory you can use this path structure in example:

body {
	background: #fff url('images/background.jpg') top center no-repeat;
}

Notice that the url(' portion is basically just looking into the images directory that is under the style.css that is calling for that image instead of using some huge http:// patch structure.

Your other graphic sets, like navigation, moods, etc behave the same way as if they were put into the main theme. If you have custom navigation graphics with it's own navstyle.css that you created, instead of going into the /comicpress/images/nav// directory you would put them into the child theme instead, such as /comicpress-yoursitename/images/nav// and ComicPress will check there as well for the options area in the dashboard when configuring your site.

5. custom-menubar.php goes into the child theme

The custom-header.php is basically a file that can be injected into the menubar position wherever it is on your site, instead of the menubar showing it will instead load this file. This allows you to create your own look and feel for your menubar. This custom-header.php file when using a child theme needs to be in the child theme directory.

6 . The widgets directory in the child theme

You can create your own custom widgets or ones that are specific for your child theme. This directory gets auto loaded when the theme gets executed to be seen in the widgets area of the dashboard.

7. Put your CSS changes into the style.css of the child theme.

In order to continue with this whole "don't edit your comicpress theme" method of thinking. Some of you use Companion to do this exact same thing. However I want to touch up on an important note to those modifying CSS. You do NOT put the entire style.css set of elements into the custom area or companion. You ONLY put changes. For example, in the main ComicPress theme's style.css you see:

body {
	margin: 0;
	font-family: 'Arial' , sans-serif;
	font-size: 14px;
	color: #000;
}

And you want to add a background to the body area and change the color from black to white. You would want to ONLY put what is changed, like this inside of the style.css of the child theme OR companion:

body {
	background: #fff url('images/background.jpg') top center no-repeat;
	color: #000;
}

Notice that not *all* of the elements are there, ONLY what is changed. This allows you to recognize what specific thing is changed instead of trying to figure out a difference between your original and your changes.

Good luck! If any of you need any assistance in creating your own custom child theme, please do not hesitate to contact me!

- Phil (Frumph)

These functions in wordpress allow you to specify a point in the code to trigger or initiate another segment of code.    Like an extension to the original code that's placed there.   This is used so that different plugins that are created can use those 'hooks' in the wordpress code to add to the original core code without having to actually edit the core code itself.

do_action()
http://codex.wordpress.org/Function_Reference/do_action

The WordPress.ORG Codex refers to the usage as:

do_action($tag, $arg = );

The $tag refers to the 'Label' you specify took hook into with your add_action function.   The $arg = refers to the arguments that you want to pass through the do_action and into the add_action.

.. That really doesn't say much on how to actually use the do_action.    What the do_action() function does is set's a label in a specific point in your code for your plugin or theme code to hook into with the add_action() function.

For example, I place a do_action() right above the blog area of my theme.

do_action('mytheme_aboveblog');

What you're doing when you add the do_action is make it so that at that place in your code you can inject some other code into it. What makes this different then actually hardcoding the function name there? Using the do_action() allows multiple functions to access that particular point in the place you put it at, not just one, which you can use to set different events to occur to trigger them to display or be used there.

add_action()
http://codex.wordpress.org/Function_Reference/add_action

The WordPress.ORG Codex refers to the usage as:

add_action($tag, $function_to_add, $priority = 10, $accepted_args = 1);

The $tag refers to the label you specified as the hook in the do_action() function.   $function_to_add refers to what the name of the function is inside your plugin to execute, $priority refers to how much of a priority is given to execution of this function and $accepted_args refers to the number of arguments passed through do_action() to the $function_to_add.

What this is really saying?   The add_action finds the label specified in the $tag and hooks into it saying to that bit of code to "execute this function in addition to what you're already doing, oh and pass these arguments."  For example, in my activity monitor plugin:

add_action('mytheme_aboveblog',  'mytheme_online_user_message');

Now, whenever the do_action checks for something to be injected into it to be used the add_action will trigger the function mytheme_online_user_message to run.

function mytheme_online_user_message() {
	global  $current_user;
	if (!empty($current_user)) {
		$user_login = addslashes($current_user->user_login);
		echo "Hello {$user_login}!";
	}
}

Now if the user is logged on it will run this function in that do_action place you put it and if the user is online inject that message into that place.

Summary

Placing a do_action()  into your code allows other functions to hook into it to extend the functionality of where that hook is placed, using add_action().

I wanted to test the page load and memory usage of both systems that are just straight bare-bones upon installation.  I added the following to the footer of Inkblot since it didn't have it to 'show' it's users.

	<p><?php echo get_num_queries() ?> queries. <?php  $unit=array('b','kb','mb','gb','tb','pb'); echo @round(memory_get_usage(true)/pow(1024,($i=floor(log(memory_get_usage(true),1024)))),2).' '.$unit[$i]; ?> Memory usage. <?php timer_stop(1) ?> seconds.</p>

What this line does is give the amount of SQL queries that the system uses, how much memory it uses and how long it took for the page to compile and load PER USER ACCESS.  Without any extra added plugins.  Take note though this is done on a server with opcode cache'ing to begin with, while ComicPress knows how to deal with Memory, WebComic does not.

OpCode Cache'ing cache's the PHP code, it is the preferred way of cache'ing if you have it available.

Let's start with ComicPress (to try to be more fair I set it to the 3C theme so it had 2 sidebars there WITH default widgets that load):

47 Queries, 3.25MB Memory Usage, 0.117 seconds load time.

Now let's look at InkBlot (no default widgets loading only one sidebar active)

Oh wait, you CANT, Inkblot requires a Plugin to actually work.   ComicPress does not, you name the files put them in the comics directory and associate the categories in the comicpress-config.php and that's all you need for a functioning working system.

So moving on, I added the WebComic Plugin and now its:

54 Queries, 15.75 MB mem used and loads in 0.574 seconds

I'm sorry, why? ^ clearly wtf.   Just to be fair I activated ComicPress Manager.

47 Queries, 3mb mem usage and load time of 0.175 seconds.

Moving on.

]]> http://frumph.net/wordpress/review-webcomic-inkblot-vs-comicpress/feed/ 12 http://frumph.net/wordpress/adding-a-check-for-custom-taxonomies-on-archivesearch-pages/ http://frumph.net/wordpress/adding-a-check-for-custom-taxonomies-on-archivesearch-pages/#comments Sat, 12 Jun 2010 04:12:47 +0000 Phil (Frumph) http://frumph.net/?p=1049 On search and archive pages there isn't a specific archive_<post_type>.php  yet so you have to edit your current archive and search to compensate for it being used for custom post types and taxonomies. On a good note, there is the $wp_query->query_vars that we can work with. (if) there is a custom post type taxonomy being set it will be in those variables.    Now here's the interesting part.    If we check for the is_category() and is_tag() ahead of the check for the query_var checks it will weed out the normal post post_type from the ones in custom post types.

<?php $post = $posts[0]; // Hack. Set $post so that the_date() works. ?>
<?php /* Category Archive */ if (is_category()) { ?>
	<h2 class="pagetitle"><?php _e('Archive for &#8216;','comicpress'); ?><?php single_cat_title() ?>&#8217;</h2>
<?php /* Tag Archive */ } elseif( is_tag() ) { ?>
	<h2 class="pagetitle"><?php _e('Posts Tagged &#8216;','comicpress'); ?><?php single_tag_title() ?>&#8217;</h2>
<?php /* Daily Archive */ } elseif (is_day()) { ?>
	<h2 class="pagetitle"><?php _e('Archive for','comicpress'); ?> <?php the_time('F jS, Y') ?></h2>
<?php /* Monthly Archive */ } elseif (is_month()) { ?>
	<h2 class="pagetitle"><?php _e('Archive for','comicpress'); ?> <?php the_time('F, Y') ?></h2>
<?php /* Yearly Archive */ } elseif (is_year()) { ?>
	<h2 class="pagetitle"><?php _e('Archive for','comicpress'); ?> <?php the_time('Y') ?></h2>
<?php /* Author Archive */ } elseif (is_author()) { ?>
	<h2 class="pagetitle"><?php _e('Author Archive','comicpress'); ?></h2>
<?php /* Paged Archive */ } elseif (isset($_GET['paged']) && !empty($_GET['paged'])) { ?>
	<h2 class="pagetitle"><?php _e('Archives','comicpress'); ?></h2>
<?php /* taxonomy */ } elseif (is_taxonomy($wp_query->query_vars['taxonomy'])) {
	if (is_term($wp_query->query_vars['term'])) { ?>
		<h2 class="pagetitle"><?php echo $wp_query->query_vars['taxonomy']; ?> - <?php echo $wp_query->query_vars['term']; ?></h2>
	<?php } else { ?>
		<h2 class="pagetitle"><?php echo $wp_query->query_vars['taxonomy']; ?></h2>
	<?php } ?>
<?php /* Post Type */ } elseif ($post->post_type !== 'post') { ?>
	<h2 class="pagetitle"><?php echo $post->post_type; ?></h2>
<?php } ?>

I know this isn't pretty and if anyone wants to rewrite it to be a little cleaner I would be grateful for that.  There also needs to be a fix for the different [pages] that occur with pagination.

- Phil

Each listing has the ability to have genre's, style's authors, designers, CMS's and some other nifty tags/keywords associated to each of the Showcases so that searching for comics that are in the same genre or by author is easily done.

Since each of the showcases are basically wordpress-posts we can include galleries and they are easily editable with post thumbnails and more.

I have articles here from the past webcomicplanet, however I do not yet know if I should integrate them back into the site.   If you care to comment please do.

- Phil

The define('NOBLOGREDIRECT', '%siteurl%'); inside of the wp-config.php makes it so that when someone enters a subdomain that does not exist on your site to redirect to whatever url you wish it to.   You can use this to have it either go to a specific FAQ page or directly back to the main root installation, anywhere you want to direct it.  the %siteurl% can be replaced for example define('NOBLOGREDIRECT', 'http://frumph.net/FAQ/site-create');

When someone in their browser tries to go to (for example) http://badsubdomain.frumph.net/ a subomain which doesn't exist, it will go to what is defined in NOBLOGREDIRECT.

Without using NOBLOGREDIRECT the (for example) http://badsubdomain.frumph.net/ - which is a subdomain that doesn't exist would direct to the signup page asking which reports whether or not the user can create the bad subdomain in question.   This is fine, there's nothing wrong with it redirecting to the signup page if someone put in a bad url.   However, those of us who think it's rather tasteful to have the user just redirect to the home page don't like that, so we want to use the NOBLOGREDIRECT to direct things to the front page; have the user look at the site first.

Now where's the behavior problem?  It's when using NOBLOGREDIRECT and on your normal use of the mainsite.   The bad behavior is when someone goes to a page on the normal site that doesn't exist.  For example http://frumph.net/idontexist/  ;  Instead of redirecting to the sites 404 page (the page not found template) it will redirect you to what is specified in NOBLOGREDIRECT.  Wait.. what?  Why does it do that?    The behavior of redirecting 404 pages is an old function used in WPMU that should not exist anymore however is left in when WPMU was merged with WordPress itself.

What can be done to fix the behavior so that it goes back to dishing out 404 pages?   Well that's easy, you just disable the function from being called that would redirect those 404's.

In your /wp-content/mu-plugins/ folder, (if you don't have one and are using multisite, you can create it manually)  you add a custom.php file to it and add a line to disable the action.

For example, create a file named custom.php  toss it into the /wp-content/mu-plugins/

custom.php

<?php
remove_action( 'template_redirect', 'maybe_redirect_404' );
?>

The function that is causing the bad behavior of not directing 404 pages properly is maybe_redirect_404() and it's being called as an add_action, so in order for us to not have the function run we remove the add_action with remove_action.

Having the custom.php file (a file we created just now) placed in the mu-plugins folder means that its automatically activated and running at all times.

Now those 404 pages are redirecting to the 404 page not found template for your theme and bad subdomains entered will go to whereever you specified in the NOBLOGREDIRECT.

- Phil