gudlyf

Ah, I see. My problem is I don’t handle archives with my theme properly. So, turning them off is just fine. 🙂

We’re talking over 20k tags. I got around the issue by increasing the maximum script size in php.ini, so I’m all set.

One other thing I noticed: it appears archive sitemaps are broken. When I tried that, the urls it gave for the archive sitemaps did not end with ‘sitemap.xml’. I turned off archives for now.

OK, it appears I “fixed” this by just forcing things along with a non-permalink visit to the sitemap. Once that was done, the permalink worked. *shrug*

@arnee —

Yes, and I just updated to this version and, as you can see, the link to generate manually is still there:

http://skitch.com/gudlyf/d3ugy/xml-sitemap-generator-cliqueclack-tv-wordpress-build-20100914120618

I’ve installed the latest alpha release successfully, but it’s behaving the same as the other versions for me, where I have a problem with the sitemap generation if done any other way than manually.

Even using the GET request doesn’t work. When I use that URL, it results in a blank page. When I go back to the XML Sitemaps settings, it reports the sitemap generation stopped after a little over 5000 entries (I have over 27000). If I click the “generate sitemap manually” link, it works perfectly. I’d LOVE at least the GET request to work, but it doesn’t.

I’ll test whatever you want to get this working.

2bak860 —

It looks like you can grab the post parent and then check its category:

<?php
$post = get_post($ID);

if ( is_object($post) ) :
  if ( ('attachment' == $post->post_type) && $post->post_parent && ($post->ID != $post->post_parent) ) :
     setup_postdata($post->post_parent);
     if ( in_category('pears') ) { echo "pears"; }
  endif;
endif;
?>

Something like that.

I’ve made a temporary fix for anyone impatient like me:

http://www.cliqueclack.com/code/2009/08/20/a-fix-for-amazon-reloaded-for-wordpress-and-amazons-new-api/

Requires you get your own Amazon AWS keys.

Good point re: options vs. reports. I made a change that does just that, however I did not make the change to allow editors and authors access to the reports by default the way I have it, since if someone didn’t want those groups to have access, the plugin would force the cap on those users anytime they upgraded the plugin.

At least this way, when you install or upgrade the plugin, the Administrator definitely gets both caps. If the blog owner wants Editors and Authors to have access, they can make the change in the manager and it won’t reset when the plugin needs to be upgraded or reinstalled.

133c133
<               $hook = add_submenu_page('index.php', __('Blog Stats'), __('Blog Stats'), 'publish_posts', 'stats', 'stats_reports_page');
---
>               $hook = add_submenu_page('index.php', __('Blog Stats'), __('Blog Stats'), 'stats_reports', 'stats', 'stats_reports_page');
136c136
<       $hook = add_submenu_page('plugins.php', __('WordPress.com Stats Plugin'), __('WordPress.com Stats'), 'manage_options', 'wpstats', 'stats_admin_page');
---
>       $hook = add_submenu_page('plugins.php', __('WordPress.com Stats Plugin'), __('WordPress.com Stats'), 'stats_options', 'wpstats', 'stats_admin_page');
588a589,596
>
>         $role = get_role('administrator');
>       if(!$role->has_cap('stats_options')) {
>               $role->add_cap('stats_options');
>       }
>       if(!$role->has_cap('stats_reports')) {
>               $role->add_cap('stats_reports');
>       }
599c607
<       if ( ( !$blog_id = stats_get_option('blog_id') ) || !stats_get_api_key() || !current_user_can( 'manage_options' ) )
---
>       if ( ( !$blog_id = stats_get_option('blog_id') ) || !stats_get_api_key() || !current_user_can( 'stats_reports' ) )
676c684
<       if ( !isset($wp_registered_widgets['dashboard_stats']) || !current_user_can( 'manage_options' ) )
---
>       if ( !isset($wp_registered_widgets['dashboard_stats']) || !current_user_can( 'stats_reports' ) )