amp343

Trying to think a little more about why the default permalink structure (again, say /%year%/%monthnum%/%postname%/ for this case) would 404 when used with a custom post type.

Upon more digging, it looks like a particular permalink structure only works for the first post type that it is registered to, custom or not. For example, I can also not use the same permalink structure for two custom post types (it only works for the first).

I guess this makes sense if WP uses the permalink structure to determine information about the page content (which post type, etc). But why should that matter if every entry has a unique slug, no matter which post type it is?

Just want to second that – adding post thumbnail support to my theme’s functions.php file did the trick.

Ah, yes – the function has to be called within the context of the page’s main query (ie, the “single” loop for posts and pages.)

If run outside the main query, the function should still “work,” but it will be retrieving the associated sidebar for the most recent queried content, not necessarily the page or post at hand.

Hey Tzaddi,

I tried duplicating the scenario you described, but couldn’t create the same problem; when I switched a page between 2 page templates (both with amp_get_sidebar() included) my AMP sidebar stayed the same on both versions without reverting to the default.

I’m sure you’ve already checked this, but the issue that comes to mind is your second template might contain the generic sidebar function get_sidebar() instead of the needed amp_get_sidebar() function.

If you want to troubleshoot and ensure the template that you intend is actually being used, try this plugin: https://www.ads-software.com/extend/plugins/show-template/. It prints an html comment that shows which template is being rendered.

Let me know if you’re able to resolve this or if the issue persists.
Thanks,
Andrew

@r3volution11 Thanks for this fix. Your comparison of the event start date meta value vs. the current time enabled me to successfully query past and upcoming events (by changing the meta_compare), whereas the built-in parameter eventDisplay never quite worked.

Does posts_per_page still not work as you expect it in this context? I changed my value to 1 (to just show the very next or previous event), and it seems to work.

Thanks again for the fix.

I have a little hack/workaround that seems to be working for displaying breadcrumbs with Custom Post Type Archive pages (3.1+).

I want to get my breadcrumb looking like this:
Home > Custom Post Type Archive > Custom Post Type Single

However, natively the plugin only generates this:
Home > Custom Post Type Single

The caveat is that you’re allowed to manually select a page as a “root”. This is where you can trick the plugin into displaying your custom post archive page as part of the breadcrumb.

Say for instance my custom post archive URL is https://www.site.com/albums/. To get this archive to show up in the breadcrumbs, I just created a page to “mimic” this URL called “albums”, and set its permalink to the exact same thing. That way, I’m allowed to select that page as a breadcrumb root — yet when the page is actually rendered, it generates the Custom Post Type Archive that lives at the same URL, not the dummy page.

Not saying this is a good idea, but it works for me!

@jrgreenfield1,

Thanks, I don’t think it does because that would effect the rest of the site as well.

The code below works really well, but I’m only looking to grab 2-3 events. Not sure where I would put the loop though

Can’t you just add the parameter ‘posts_per_page=x’ to your query_string() call? So, query_posts($query_string . '&category_name=events&posts_per_page=2'); , for example? Seems like that should work.

Switching from Excel to OpenOffice worked to solve this problem for my CSV import

Is there an advantage of actually printing out the explicit “rel” value for each of your image links, vs. setting prettyPhoto with jQuery?

Just off the top of my head, I would think it would be pretty easy to just say,

$(document).ready(function(){

   $(".gallery a").prettyPhoto();

});

… or something of the like? to make all <a> tags inside elements with the .gallery class receive the prettyPhoto behavior.

^ Yes, tedium is the main reason for not doing it that way.

If I have to, I have to, but not looking forward to spending a day that way.

Hey jdembowski, thanks for the reply.

I tried out your suggestion, however it’s not quite what I’m looking to do. It does do a good job of showing which files exist / don’t exist between the two directories, though, so I’ll have to keep that snippet on hand in case I need to refer to it, thanks.

In this case, I’m trying to figure out if the contents of each file is different. I know that the file names and locations will be mostly the same. The real question is which files have inconsistent contents. Any other suggestions?

I’m totally useless with this UNIX command type of stuff, but your first suggestion seems to be a good start.

Thanks again!

Hey poil –

That’s a good thought – but it didn’t end up being the problem.

Apparently, the issue was that the meta_id column in the wp_postmeta table had been altered (by some sort of plugin? I had a ton installed trying to pick the best one for custom field management) so that the primary key and auto-increment had been removed.

I uninstalled all my custom fields plugins. Then I went into my phpMyAdmin, restored these attributes to the wp_postmeta > meta_id column, and the plugin seems to be working according to plan.

We’ll see if it stays that way!

Hmm… a re-activation of the plugin seemed to do the trick – but make sure you save your CSS and other custom settings before doing that, if you experience the same thing.

So hopefully, this solved it.

You could also try

<?php echo get_post_meta($post->ID, 'Favorite Fruits', false); ?>

…with the last argument FALSE instead of true. That argument tells the function whether or not to return a single value.

Well, looks like I’m able to answer my own question after researching a bit more:

When you try to sort by a numeric query using the query_posts() function, PHP interprets it as a string. So, 10 is interpreted as “1”, etc… which, you can imagine, throws the sorting all off.

In order to get around this, I had to use a custom select query rather than the query_posts() function – and also use this fix as part of my query:

https://www.ads-software.com/support/topic/286391?replies=12

Essentially, including this line
ORDER BY wpostmeta.meta_value+0 DESC
forces the field to be interpreted as an integer rather than a string – exactly what I was trying to do. Sorting works just as I had intended.