Jacob Dunn

Ah – ok. That makes sense. On line 764, add this last else statement:

}else return;

That should at least resolve the warning. Is there still no options page in the admin for you? How are you enabling the archives?

Sorry I didn’t get to this sooner, newcom1 – been a bit swamped with work, as of late.

Took a look at the code indicated by your error, and I have to admit, I’m at a bit of a loss. There appears to be no apparent reason you’d get that type of error in that function. Not to say it couldn’t happen – it apparently did D:

If you happen to still have the plugin installed, could you check to confirm that the function get_bases is on line 759, and maybe do a print_r on $this->_rewrites, see what it spits out?

To trigger that function, you’ll need to hit ‘save’ on the permalinks page, seeing as you can’t get to the options page for this plugin

Speaking of which, this has become a real issue – you’re not the first or last to mention the options page not showing up. It’s become a bit of a pain really – I can’t track down what the issue is, I’m actually using the recommended code for adding option pages verbatim. If you can tell me what additional plugins you have, or any other information that’s valuable, I’d truly appreciate it.

Thanks!

Thanks mp – I took a look to see if that is the issue, but I’m thinking Dr. Brown may be off in this case. The ‘plugin_action_links’ hook still exists, it’s just been moved to the ‘class-wp-plugins-list-table.php’ file in 3.1. It’s also not the hook that’s involved with displaying the admin menu – it’s used to add the ‘settings’ link to the plugin description on your installation’s plugin page.

The functions used by this plugin to add itself to the admin menu is the hook ‘admin_menu’ on line 31 and the function ‘admin_menu’ on line 166-169 in config.php. If you want to debug, a few print statements around those locations may reveal whether those functions are even being called….

I’ve also tested this plugin thoroughly in every release client/new release, as it’s very dependent on bleeding edge WordPress developments – don’t want to be caught off guard ??

That being said, we DO need to see if we can get the root of your issue – you’re not the first to mention this page not showing up, actually, so I know an issue is being caused somewhere, I just don’t know how to reproduce it. What other plugins do you have in your installation? Any unusual code in the template? Anything used to modify the Admin’s appearance? If it’s not a vanilla install of WordPress, I’m guessing there’s some other influence at work here.

The Custom Post Archives plugin will include custom posts in requests where there is no specific post type specified if there are custom posts showing in the current page’s default query.

^ Wow – that reads back about as convoluted as I thought it would. The short of it is, though, that this added logic was able to address a lot of issues that the WordPress core has either not seen or intentionally ignored during their custom post implementation in 3.0. I’m guessing ignored, as they haven’t fixed any of it in 3.1.

However, that doesn’t address the issue at hand – and it is and issue. I’ll be doing some testing later on to see if I can find a reasonable work-around, and will let you know if I find a fix – which will be included in the next update.

Thanks for your patience!

Sorry to hear there are issues, Jason. I’ll try to help, but I may need you to clarify a few points, first. What do you mean it doesn’t add archives to the menu? Is that the site menu, or the wordpress admin? It may help if you send a screenshot of the issue, or the settings screen. You can email me at [email protected].

You just made my day :). Glad that it’s still of help to – and glad to hear it still works with 3.1. I had tested the new archive functionality from 3.1 when it was still a ticket, but haven’t had the opportunity to test the full release yet.

Yes, you’re right, there’s some ambiguity surrounding that check-box, now that I look at it. I’ll try to clarify the UI a bit with the next update. For the record, the plugin automatically adds a feed-specific RSS feed, the RSS feed check-box is to include those posts in the main blog RSS feed, as well. I have that somewhere else in the help section, I think, but it needs to be more readily apparent than that.

Hope that helps!

Feel like I need to clarify again – this plugin will create an archive page for a custom post type, but doesn’t take any part in user restrictions. For that type of functionality, you’ll need to use something like the Role Scoper plugin.

Best of luck though – and yes, the best way to learn is to screw up. And often ??

For the situation you’re outlining, this plugin can only provide a piece – and only if the “story” post types are custom, and not just a category. For the other two columns, it would probably work best to write custom loops.

So, to accomplish this while using this plugin:

• Activate the archive for the “story” post type
• Create a copy of your “archive.php” file, titled “archive-story.php” in your templates directory
• Add the two custom loops you’re displaying to the side

Glad the trunk worked, at least. This appears to be a widespread issue, there is a ticket opened in trac for it already. Hope it doesn’t cause issue with any of your other plugins ??

I had noticed that as well…it seems that www.ads-software.com is having some issues. After pushing this update last night, it seemed to 404 maybe a 1/3 of the time. You can try updating again, or download manually here:

https://downloads.www.ads-software.com/plugin/custom-post-archives.1.0.2.zip

If that doesn’t work, the trunk version hasn’t been modified since the update, yet:

https://downloads.www.ads-software.com/plugin/custom-post-archives.zip

I don’t know what’s up with www.ads-software.com, but I’ll probably mess around with this later to see if any other plug-in authors have experienced similar issues.

Again, sorry for any misunderstanding the wording of the summary may have caused. Any implications of this or any other unsupported functionality was inadvertent. I’ve always thought of “pages” as the content presented on the front end, and “templates” as the php files used to format and display that content. I will attempt to correct any ambiguity during the next update – I certainly don’t want any confusion.

As far as the suggestion that this plug-in should have actually created those files in the template directory during plugin activation, I believe that would be far outside the scope of this or any other plugin. There is no way to predict what code should be contained in a template file, as it’s structure is intimately tied to the currently active theme. The only way to correctly follow whatever framework is being used would be to simply copy and rename the archive.php file, but that would be pointless as that would only create duplicate and absolutely redundant code. And it also would create the type of situation you were afraid of – loose code inserted without consent into the core of your site, that remained even after plug-in deactivation. Understandably, that would make people…upset.

Thank you for your input – I will be sure to update the description to be less misleading. Feel free to let me know if there are any other issues with the plug-in.

The summary states that the plug-in “Extends upon the WordPress templating”, not that it creates the templates. None of those files are created by default, you have the option of creating them if you would like more fine-grained control of the output. Otherwise, this plug-in uses the archives.php and then index.php files in your templates folder, in that order.

For a more in-depth look into which files this plug-in looks for while searching for templates, check the first question in the faq.

For a look at how WordPress templating works, I’d take a look at this page: https://codex.www.ads-software.com/Template_Hierarchy

I hadn’t even thought of that – however, looking at the get_calendar function in wp-includes/general-template.php, it appears they’ve hard-coded in the post-type that is retrieved for the calendar. So, short of creating a custom widget, it doesn’t look too promising.

I’ll let you know if I think of anything, though!

That’s a bit odd. Do you happen to know what version of PHP your server is running? I have a string in the plug-in that uses Heredoc syntax, but that has been supported since PHP 4. Other than that, I don’t know what else could have caused the issue. If you could send a screenshot of the error to [email protected], it may help me pin down the issue.

iporter – the issue was exactly what you thought, it was called too early. Fix here.