get_queried_object

Scenario: On a custom taxonomy page. (In this case the custom taxonomy is called "Product Category" – the specific category/term page we're on is "Accessories". To get specific details on the term – I used get_queried_object (which is a pretty useless codex page – there's barely any information there)

$term = $wp_query->get_queried_object();

This is what $term looks like:

stdClass Object
(
[term_id] => 5
[name] => Accessories
[slug] => accessories
[term_group] => 0
[term_taxonomy_id] => 5
[taxonomy] => product-category
[description] =>
[parent] => 0
[count] => 7
)

get_queried_object on a page looks something like this:

[ID] => 6
[post_author] => 1
[post_date] => 2010-03-29 05:38:46
[post_date_gmt] => 2010-03-29 05:38:46
[post_content] => This is my page content. Woo hoo! Hi.
[post_title] => My Totally Awesome Page
[post_excerpt] =>
[post_status] => publish
[comment_status] => open
[ping_status] => open
[post_password] =>
[post_name] => my-totally-awesome-page
[to_ping] =>
[pinged] =>
[post_modified] => 2010-10-04 16:43:41
[post_modified_gmt] => 2010-10-04 22:43:41
[post_content_filtered] =>
[post_parent] => 0
[guid] => http://www.mydomain.com/?page_id=6
[menu_order] => 3
[post_type] => page
[post_mime_type] =>
[comment_count] => 1
[ancestors] => Array
(
)
[filter] => page

On a category archive page – this is what the object looks like:

[term_id] => 3
[name] => Press Releases
[slug] => press-releases
[term_group] => 0
[term_taxonomy_id] => 3
[taxonomy] => category
[description] =>
[parent] => 0
[count] => 21
[cat_ID] => 3
[category_count] => 21
[category_description] =>
[cat_name] => Press Releases
[category_nicename] => press-releases
[category_parent] => 0

get_categories

Scenario: We want to get a list of terms in a custom taxonomy. Here are our $args:

'parent' => (A PRENT CAT ID),
'hide_empty' => 0,
'taxonomy' => 'location'

Then we pull in the list via get_categories

$mycats = get_categories($args)

This is one of the objects in $mycats (Can get one via a for each loop…)

[term_id] => 1393
[name] => Central Florida
[slug] => central-florida
[term_group] => 0
[term_taxonomy_id] => 1401
[taxonomy] => location
[description] =>
[parent] => 27
[count] => 3
[cat_ID] => 1393
[category_count] => 3
[category_description] =>
[cat_name] => Central Florida
[category_nicename] => central-florida
[category_parent] => 27

get_term_by

Scenario: get information on a specific term using get_term_by

The example below was done using get_term_by('id'… etc. Here is what the object looks like that I got back:

[term_id] => 24
[name] => Northern California
[slug] => northern-california
[term_group] => 0
[term_taxonomy_id] => 24
[taxonomy] => location
[description] =>
[parent] => 23
[count] => 24

I'll continue to add to this post over time. I've had it sitting in draft forever – but figured it was time to hit the publish button already. I think it's interesting to note that in the above objects – we're looking at a particular term in a taxonomy – but depending on how we obtained it – will also depend on what elements are in that object. ie. the presence of "cat_ID" in one "category_count" (not sure how this is different than "count", also not really sure what "term_taxonomy_id" is but I notice that it doesn't always equal term_id – so these two are not one and the same…

get_children

I use get_children very often to get all attached images to a post. When I do, the code usually looks like this:

$images = get_children(array(
'post_type' => 'attachment',
'post_status' => null,
'post_parent' => $post->ID,
'post_mime_type' => 'image',
'order' => 'ASC',
'orderby' => 'menu_order ID'));

$images will have multiple objects in it (if there are multiple images attached) here's an example of one of them:

[ID] => 1171
[post_author] => 2
[post_date] => 2011-10-02 21:11:39
[post_date_gmt] => 2011-10-03 03:11:39
[post_content] => (FYI - this is the image description)
[post_title] => IMG_2168.jpg
[post_excerpt] => (FYI - This is the image caption)
[post_status] => inherit
[comment_status] => open
[ping_status] => open
[post_password] =>
[post_name] => img_2168-jpg
[to_ping] =>
[pinged] =>
[post_modified] => 2011-10-02 21:11:39
[post_modified_gmt] => 2011-10-03 03:11:39
[post_content_filtered] =>
[post_parent] => 1173
[guid] => http://www.domain.com/wp-content/uploads/2011/10/IMG_2168.jpg
[menu_order] => 0
[post_type] => attachment
[post_mime_type] => image/jpeg
[comment_count] => 0
[filter] => raw

Related posts:

1. WordPress Pagination Woes (solved? I hope?) For awhile now, I've run into pagination problems when doing...
2. WordPress edit_post_link doesn't display (fix) I recently ran into this problem – and I see...

Related posts brought to you by Yet Another Related Posts Plugin.

My original plan was to use this plugin: Cache Images – to import the pictures. The reason being that I needed the images attached to their various posts for the template – which is what that plugin does in addition to loading all externally referenced images onto your own server. But the way Typepad is storing the images now, the plugin doesn't really work. The images are referenced without a file extension at the end – which is what that plugin specifically uses to search for images. So that is why I used HTTrack to pull down the images first.

After I had a folder of all the images for the site – I put that up on a DIFFERENT server. (I know, a little confusing but hang in there with me)

I then used the search regex plugin to change references to the images without an extension to the temporary location of those images on my other server – but this time WITH the .jpg extensions:

Search string (regex options turned on)
#src="http://www.MY-CLIENTS-TYPEPAD-DOMAIN.com/\.a/([^\s]+(?=))"#i
and replaced it with:
src="http://MYREMOTESERVER.COM/DIRECTORYNAME/$1.jpg"

Now with all the references using the appropriate .jpg extension and pointing to MY server, I was then able to go back and use the "Cache Images" plugin to pull down the images and attach them to their respective posts.

Related posts:

1. The mysteriously disappearing WordPress 3.1 Admin Bar I've run into this problem a few times now and...
2. WordPress emails being sent by {username}@box###.bluehost.com (fix) If you are hosted on Bluehost and you're using WordPress,...
3. WordPress edit_post_link doesn't display (fix) I recently ran into this problem – and I see...

Related posts brought to you by Yet Another Related Posts Plugin.

Another possibility is that a plugin is misbehaving – so you can try disabling plugins – but before you do that – (if you have a lot of plugins certainly) try this next step first!

In my case the problem usually stems from the fact that I like to keep my WordPress files in their own directory, and then run the site itself in the root directory. However, if you view your site before you move it to the root diretory… the cookie that determines whether or not the admin bar should be displayed may have already been set – and it will be set to your WordPress directory – not the directory (or root) that your site is now living. The fix is simple: clear your cookies for your site, (which will effectively log you out too if you haven't logged out already) – log back in – and then it should be fixed.

Related posts:

1. WordPress edit_post_link doesn't display (fix) I recently ran into this problem – and I see...
2. WordPress emails being sent by {username}@box###.bluehost.com (fix) If you are hosted on Bluehost and you're using WordPress,...
3. WordPress Pagination Woes (solved? I hope?) For awhile now, I've run into pagination problems when doing...

Related posts brought to you by Yet Another Related Posts Plugin.

$paged = (get_query_var('paged')) ? get_query_var('paged') : 1;

That's the key to getting the next_posts_link() and previous_posts_link() working. So you have this on your custom template:

$paged = get_query_var( 'page' ) ? get_query_var( 'page' ) : 1;
$args = array(
'post_type'=>'my_custom_post_type',
'paged' => $paged
);
query_posts( $args );

And then this will paginate the content:

next_posts_link('Older Posts');
previous_posts_link('Newer Posts');

If you need to make use of any information regarding the current page (not referencing your custom query – then you'll probably need this after you loop through your custom query:

wp_reset_query();

However, in my most recent use, get_query_var('paged') always returned "1" no matter what page I was on. After much searching, I finally found out, if you're using a custom template for the homepage, and you're using a custom query for the posts displayed on that page, then you have to do this instead:

$paged = (get_query_var('page')) ? get_query_var('page') : 1;

(note the use of "page" vs. "paged")
Why these two values are different, I'm not sure, but they are… and this was the only thing that got pagination working on the custom template for the homepage.

Then there was another wrinkle I discovered. If you're doing a custom select query to get posts – then this forum post has this important code to get the pagination working – as there are some variables that do not get populated with a custom select query, and are needed for pagination:

$total = "your custom select query goes here, but without LIMIT and OFFSET, so the total number of posts that match the query can be counted";
$totalposts = $wpdb->get_results($total, OBJECT);
$ppp = intval(get_query_var('posts_per_page'));
$wp_query->found_posts = count($totalposts);
$wp_query->max_num_pages = ceil($wp_query->found_posts / $ppp);
$paged = (get_query_var('page')) ? get_query_var('page') : 1;
// or use the below for custom select queries used on a homepage custom template
//$paged = (get_query_var('paged')) ? get_query_var('paged') : 1;
$offset = ($paged-1) * $ppp;
$wp_query->request = "your query again, but with the LIMIT and OFFSET as follows: LIMIT $ppp OFFSET $offset";
$pageposts = $wpdb->get_results($wp_query->request, OBJECT);

Then, after you foreach loop – you can use the next_posts_link(), previous_posts_link() to show the pagination…

Another tidbit I discovered along with this… when doing a custom select query loop, you'll have something similar to this:

foreach ($pageposts as $post):
setup_postdata($post);
... stuff for your template like <h1><?php the_title(); ?>
etc...
endforeach;

If you use a different variable name other than "$post" in that foreach call – it's not going to work 100% right. Tags like the_title() will display the title for the current page (that's using the custom template) not the page/post within your custom loop.

I realize this is not an in-depth how-to type post, still I hope this information helps someone struggling with the same things I was

Related posts:

1. WordPress edit_post_link doesn't display (fix) I recently ran into this problem – and I see...

Related posts brought to you by Yet Another Related Posts Plugin.

Set up a new WordPress install. Logged in. Among a few other changes, I also changed the path for the site URL in the general settings to be the domain root (rather than the directory where WordPress was installed). I had made a custom theme with "edit this page" links… but they weren't showing up.

The reason: when I logged in the first time, the "admin" cookie that was set was specific to the directory where I installed WordPress – and did not apply to the root domain where it was now pointed. Since that change happened AFTER I was already logged in, WordPress did not update my cookie to include the root directory – so those pages could not see that I was in fact logged in.

The simplest fix is to log out and then log back in – which should set your cookies appropriately.

Related posts:

1. WordPress emails being sent by {username}@box###.bluehost.com (fix) If you are hosted on Bluehost and you're using WordPress,...

Related posts brought to you by Yet Another Related Posts Plugin.

If you don't like the "wordpress@yourdomain.com" email format either – you can change that address via a plugin like: wp-mailfrom. However, again – whatever address you set it to in there – still needs to exist in your account. So if you prefer to have the from emails be ilovewordpress@yourdomain.com; make sure there is a ilovewordpress@yourdomain.com email account, forwarder or autoresponder.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

When you use wp_nav_menu() to create your nav bar, it will automatically add a container div that wraps around your navigation (which is presented in an unordered list). However, maybe you don't want that div there. According to the codex, you should only have to create your nav with 'container' => false to get that container to go away, but for some reason, on what was seeming like random occasions, it would have no affect.

Well, I realized that the reason for this is because I had not yet set up my menu specifically. As soon as I went into the admin, created a menu, and assigned it to the same location wp_nav_menu() was calling, voila! The container went away.

I understand that if there is no menu set up yet, that wp_nav_menu() resorts to calling wp_list_pages(), but it should still pay attention to the arguments passed to the original function. However, it definitely seems like it is having issues. Not sure if that's a bug or not, but now I know (or at least I THINK I know) what's happening and how to fix it.

Reference: WordPress 3.0.1

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

First, if your theme doesn't already have a functions.php file, go ahead and create one. Then add the following PHP code:

register_nav_menus( array(
'mainnav' => 'Main Nav'
) );

"mainnav" (which is the menu's "slug" and shown as "Main Nav" in the admin) is just what I came up with – but you can name it whatever you want, and you can have multiple nav menus if you want. Just register them all in that functions file. Here's an example with 3 nav menus:

register_nav_menus( array(
'mainnav' => 'Main Nav',
'navtwo' => 'Nav Bar Two',
'navthree' => 'Nav Bar Three',
) );

That's it – What that does is tell your theme you're going to have three different/unique menus. You can use them as many times as you want, wherever you want in your theme.

You'll create your menus in the WordPress admin – this is pretty self explanatory (and described pretty well here) – add pages, categories, custom links that point outside your blog, whatever you want. Give the menu a name and "apply" it to a location:

Now – to add it to your theme… You get a whole bunch of options so if you need the menu to display one way in one location, and a different way in another location – you can do that!

Here's a simple example where I've stripped out the nav "wrapper" and any automatic styling it would add – just drop this in your theme file where you want the menu to show up (like your header.php, or footer.php… wherever)

$args = array( 'menu' => 'mainnav', 'container' => false, 'menu_id' => false, 'menu_class' => false);
wp_nav_menu($args);

But you can insert an ID or a class. This is detailed pretty well here.

I've already started to use this and it's great. Clients have been really happy that they can now manage their own menus without requiring edits to a template.

Updated to add: As pointed out by Stephen in the comments – if you are creating themes for general public use and you're not sure what version of WordPress your userbase will be running – you will want to wrap these new functions in a "if (function_exists('new-fancy-function-name-here')) { … }". He has details on this on his site here. In there, he linked to another article that would have helped me out a lot had Google liked the page more so I could have found it when I was working on this recently – but there's some additional reading here on how to set all this up (it's a lot more in depth than I got into – I guess my version is the "Cliff Notes")

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I found this post on ArtLung: Migrating an old Blogger Blog To WordPress – which was a HUGE help. The gist of that was you need to download an export file from Blogger, then get this script you run from the terminal (on Mac) which will convert the Blogger xml into a xml that WordPress will understand. (Just to give you an idea what we're talking about – the Blogger XML file I downloaded was over 40MB.)

THEN the fun began. After the conversion to WordPress XML – the file was still about 30MB. This meant that I had to run the import over a dozen times before it could chew through the whole file. When the import times out and you run it again, it recognizes that some posts are already there, so it doesn't import them a second time – but for some reason, it seemed to have trouble with a bunch of comments. Some of the comments DID get imported more than once. As well – the comment counts for each post weren't getting updated. SO! Here's the fix I pieced together for those issues.

First, to remove the duplicate comments – in PHPMyAdmin – I ran the following SQL command: (*DISCLAIMER: make sure you backup your database before attempting any of this!!)

CREATE TABLE temp_table AS SELECT * FROM wp_comments WHERE 1 GROUP BY `comment_post_ID`,`comment_content`,`comment_date`;

What that does is create a duplicate of the wp_comments table – but it's only grabbing the unique entries. If a comment is posted to the same post, has the same content and the same date – we'll just be grabbing one of those and ignoring the rest.

UPDATED TO ADD: One important thing I need to add in here is that you need to set the primary keys and a few indexes for this new table – This is the structure of a normal wp_comments table:

CREATE TABLE `wp_comments` (
`comment_ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`comment_post_ID` bigint(20) unsigned NOT NULL DEFAULT '0',
`comment_author` tinytext NOT NULL,
`comment_author_email` varchar(100) NOT NULL DEFAULT '',
`comment_author_url` varchar(200) NOT NULL DEFAULT '',
`comment_author_IP` varchar(100) NOT NULL DEFAULT '',
`comment_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`comment_date_gmt` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`comment_content` text NOT NULL,
`comment_karma` int(11) NOT NULL DEFAULT '0',
`comment_approved` varchar(20) NOT NULL DEFAULT '1',
`comment_agent` varchar(255) NOT NULL DEFAULT '',
`comment_type` varchar(20) NOT NULL DEFAULT '',
`comment_parent` bigint(20) unsigned NOT NULL DEFAULT '0',
`user_id` bigint(20) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`comment_ID`),
KEY `comment_approved` (`comment_approved`),
KEY `comment_post_ID` (`comment_post_ID`),
KEY `comment_approved_date_gmt` (`comment_approved`,`comment_date_gmt`),
KEY `comment_date_gmt` (`comment_date_gmt`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=2 ;

THEN, I ran this SQL command;

DROP TABLE wp_comments;
RENAME TABLE temp_table TO wp_comments;

What that does is delete the wp_comments table, then we rename our new and improved "temp_table" so that it is now the official wp_comments table.

NEXT – we want to update the comment counts. To save having to recount the comments each time – there is a field in the wp_posts table that stores the total number of comments. However, with the way this import worked, those numbers did not get updated so most were saying there were 0 comments on posts that did have comments. To fix that issue I ran the following SQL command: (which I found here on Planet MySQL)

UPDATE wp_posts wpp
LEFT JOIN
(SELECT comment_post_id AS c_post_id, count(*) AS cnt FROM wp_comments
WHERE comment_approved = 1 GROUP BY comment_post_id) wpc
ON wpp.id=wpc.c_post_id
SET wpp.comment_count=wpc.cnt
WHERE wpp.post_type IN ('post', 'page')
AND (wpp.comment_count!=wpc.cnt OR (wpp.comment_count != 0 AND wpc.cnt IS NULL));

Which as far as I can tell gets the comment counts for each post in wp_posts. (I can't tell you more than that because once you start getting into the "LEFT JOIN" stuff in sql, my brain shuts off)

The other piece advice I'll give is if you have a ginormous blog that you have to move like the one I was working with – set the blog up locally using MAMP, do the imports, all the database correcting stuff – then just export the database and import it onto your server. The database file ended up only being 14MB uncompressed – way better than trying to chew through a 30MB import file. Once the database is up on your server, a few more SQL commands (just like if you're moving your blog to a new domain) to change the local version (probably http://localhost:8888 ) to your actual domain name, and you're done!

Another tidbit to add: if you need to redirect blogger formatted url (that may include ".html" in the end) – add this to your htaccess file and it should redirect to the new (non extension ending) URL:

RewriteEngine On
RewriteRule (.*)\.html $1 [R=301,L]

(I tooke off the first line and put the second line under the "RewriteEngine On" that WordPress has in it's htaccess block and it worked great)

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Well, one problem here is that WordPress pages (at least as of this writing – with WordPress in version 2.8.5) do not have excerpts for pages. Only for posts. The way around this is to use the <!-- more --> tag where you want your break. So that works fine – but what about stripping out the images? I'm still working on my reg-ex knowledge, but I found this one from here and it worked for me. So this is what I'm doing when I'm pulling in my page excerpt:

<?php
$posts = query_posts('page_id=1234');
if (have_posts()) : while (have_posts()) : the_post();
//this makes the more work...
global $more; $more = 0;
?>
<h1><?php the_title(); ?></h1>
<?php
$content = get_the_content('');
$content = preg_replace('/<img[^>]+>/is', '', $content);
echo $content;
?>
<p><a href="<?php the_permalink(1234); ?>"><img src="/images/more.gif" /></a></p>
<?php endwhile; endif; ?>

*we're assuming "1234" is the ID of my page in the example above…

You'll also notice I manually added my "more" button image…

To read more about the more tag (and see where I got that global $more; $more = 0; from, you can see the WordPress codex here on the subject. (Scroll to the very bottom of the page – to the section title "How to use Read More in Pages")

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.